56 karma · joined November 28, 2018
Been there done that - SRE/DevOps/SecEng/SysEng/SoftEng
What do you truly truly enjoy?
It's easy for me to ask you question.
Often times, the answer lies within.
PS: Please enjoy the time with your child; It doesn't come often in a life time :)
The reason I think self-critique takes a rather extreme turn is because of anxiety. If we analyse the root cause, there may be more than _just_ anxiety at play but I do feel it plays a significant role(IANAD though; just an observer).
Every programmer first and foremost are humans. And as humans, we are bounded by the highs and lows of the software we develop. Some of the low self-esteem can come because _life_; some might be because they hold their bar too high to achieve dramatically; some because, they might think of engineering software as an easy-peasy task but find that it can _sometime_ come with unseen/unheard baggages; all or partial part of the aforementioned causes could lead further to be in said state of mind.
To some extent, we(as in software people) need to be brave, hold our self beliefs/values, try to elevate our self-esteem and recommend our friends/family/colleagues to do the same. It's this collective esteem that will carry us together in this journey. It's not easy to overcome fear, anxiety, depression or any other state of mind(IANAD though; just an observer). I am cognisant of the fact that it is definitely easier said than done but do note that humans are capable of achieving marvelous things both intellectually and viscerally.
Perhaps, try to be social, go out and about, have hobbies, meditation, hiking, exercise - just to name a few that helped others I have met.
Last but not the least, I cannot let myself buy the argument that someone thinks of themselves as dumb. It's extremely more likely that one has not had the opportunity to have the __foundational__ understanding and the shift required to think laterally in those terms. To acquire those, perhaps try to read more books and experiment more. These are more valuable use of time IMHO than to be harsh on oneself. But, to re-iterate, we are all humans at the end of the day.
If you want go deep, you will need to refresh/learn few key mathematical foundations that form the basis of QC. They are definitely not hard IMHO. If so, then read Michael Nielsen and Isaac Chuang excellent book https://en.wikipedia.org/wiki/Quantum_Computation_and_Quantu...
- Your typical service driven stuff (aka full-stack/backend/microservice et. al)
- Tons and tons of opensource projects from AWS (investing), Microsoft (investing) and Google (yes, investing) to name a few off the top of my head.
- Startups have so to speak started embracing Rust https://corrode.dev/podcast/
- Embedded Systems <- C/C++/ASM's bread and butter traditionally.
- Rust ecosystem is maturing faster than anything I have seen in the past (ok, maybe Go's ecosystem was fast as well).
Regarding AI and ML stuffs: While I do agree that chasing such hype may be intangible in the very short to short time frame. No doubt, the AI winter may follow a typical curve and follow up with a AI "summer". _Every_ major technology in the past 20-30 years has followed a V curve. AI/ML probably won't be an exception.
I understand that the OP may have hobbies outside of "learning" but making a dedicated time outside of it will yield by leaps and bounds. Always be learning (make time for it) - that's the gist in short without going into the nitty gritties.
My two cents: o Learn machine learning, artificial intelligence - fast.ai
o Learn Rust, Rust, Rust and some Go
o Scala is good. Keep it. All the stuff you learnt whilst using Scala and Python will be useful in _Rust_.
o SDE is huge. Try something other can webdev and gamedev.
No matter what others may say next frontier will be roughly these: - Artifical Intelligence - Quantum Computing
Get good at these. Now, is the right time.
Heh. Thanks for raising. I am very well aware of it.
> Getting this right is much harder than it sounds.
Let's call a duck a duck. Unless, you tell me you are designing guidance system for NASA, I'd be happy to leave this pedantic discussion aside.
Fair dinkum. That's you. You may be biased towards it due to past experiences and I understand it. However, with that mentality where there are no "innovation"(s) involved, you'll only get donkeys that live within the echo chamber. And, may be that's what you want.
Geez ever wondered why? It is partly due to the "monkey" work that's required. I feel the "ops" world needs a heavy reset (may sound like broken record again: eliminate toil, eliminate side-effects, chicken/egg problems, test? what test? etc..). Geez and I wonder why positions at "FANG" like places require software engineers to fill in the ops work - the engineers, the thinkers and the leaders at these companies understood pretty early on the importance of "engineering" applied to these "ops" and "qa" disciplines.
Given by today's standard, _most_ if not all the code I review out in the wild are these: - Search your question on $search_engine - Land to stackoverflow - Copy - Paste - Write some crappy unit test (important but still crappy IMHO) - CI - Boom land on production
Where is this special fairy of "overburden"'ed devs you speak of?
Very few code today are _true_ innovations. It's a pile of abstractions over abstraction shite.
And vice-versa (should of said).
Please. Doing a perfunctory role does not equate to "overburden". I'll get grads from a third-world who will _happily_ take the burden off these developers if you so insist.
> I do think management often has no idea how many different specialties and expertise there are within engineering.
That is true. It is every one's responsibility to inform mgmt of this and keep open channel.
Not necessarily. Those functions carried out by experts are best left to the experts. What software devs in a "shift left" environment _can_ and _should_(IMHO) do is to augment their capability via "self-service" platforms and those experts should do everything they can to make it accessible. It may take few rounds of PoCs/Experiments but it is well worth the endeavour.
I may sound like a broken record. Sorry.
I agree to that 100%. This is why I keep sounding like a broken record to young devs.
There are far more important and larger piece of shifting "left" which developers do not yet fully come to grapple with. Let me spell it out for you: - Information Security practices - Platform/DevOps practices - Networking Concepts 101: Are these new 20 something devs cognisant of the famous "fallacies of distributed computing"?
Peoples Republic of United States.
Sounds the same.
Possibly, a lot of us enjoy developing X in Y for the sake of doing so. Not everyone may end up caring about the value that the user gets.
Amen :)
Imagine you are in a boxing match, and your opponent looses the fight. The person who wins the fight would tell the opponent that they did well regardless; It's a courtesy. A sane person does not go around the ring saying "Ha ha you lost the fight". Is that right?
Similarly, I disagree that things need to be __that__ explicit.
Be.
Wrong.
More.
Corollary: Be right less.
Being, wrong is a humble space to be in! Mind you, you can be the smartest chipmunk in the room; But, i think being curious _and_ being inquisitive is more important than *trying* to be right and turning out to be wrong.
Modern network protocols have so much extra reserved bits that you can add pretty much anything want in it; keep going ;)