[gitfan86]

I have been in a similar boat. I was spending a bunch of time avoiding extra API calls and extra renders in React and the team I was working with didn't seem to understand that there were potential performance issues around that. They said "just use memo"

On the other hand I think it is a natural progression. 30 years ago experienced engineers would look at young people who didn't know how to fix a PCB or read bytecode and think it was a shame. If everyone had to get a computer engineering degree and work at several different roles before they could even build a UI, that would be bad for productivity.

[debaserab2]

It does make you wonder what is going to get missed though, doesn't it? Each generation gets to work on a level of abstraction higher than the one before it.

I think about that often when I think about all the things I don't understand about hardware and EE.

[gitfan86]

I did computer engineering in school 20 years ago, and have always enjoyed understanding technology. So I know what is happening from the gate in the cpu all the way up to the pixel in the monitor. The downside is that I'm spread pretty thin. I can't pass leetcode exams in the 30 minutes of allotted time, ops people can't understand why I don't use containers, and my knowledge is probably useless in making a modern CPU.

[lowercased]

At some point, you may have to look beyond traditional employment situations to best make use of your technical knowledge and experience. However, it might mean moving to consulting and possibly 'selling' yourself on a more regular/periodic basis.

I have soldered chips to boards .... close to 40 years ago, and plugged enough cards/cables together to last a lifetime. (I really don't like hardware stuff!). I've done basic Z80 and 6502 assembly up to ... web stuff today, and loads in between. I can passably describe the innards of some layer of various SQL engines, have compiled linux kernels and various packages from scratch, configured mail gateways, debugged DNS, setup/managed firewalls and intrusion detection systems, can often diagnose various application performance issues from description of symptoms alone, and can do many other things 'tech' related. (not trying to brag - loads of people here can likely do all of this, and more, and better, than me).

BUT... this set of skills often doesn't fit well within a traditional 'job' role. Finding situations where people can get/extract value from a wide variety of your skills is difficult (but can be rewarding when it's done).

I also can't do leetcode stuff, struggle with some 'point/click' things that others seem to find natural, and it can take me longer to 'produce' compared to others (although, I've often found myself cleaning up after others' projects when they leave).

I hope you have found (or can find) some situations that make the most of your skills, experience and perspectives!

[fragmede]

There are still places that need and are looking for that sort of help! Especially inside smaller cloud companies (Digital Ocean, Linode, etc) (or any company that's got their own datacenters, eg Facebook) where the solution to a problem can't be to use some AWS service. A heavy hitting sysadmin (embrace calling it devops instead) like yourself is necessary to getting stuff off the ground to a proof of concept stage, then to production.

Grinding leetcode is falling out of fashion anyway for many reasons, (but Leetcode will never tell you that), but it's still a skill to practice up on and be able to make it past an easy question without problem. It's not a skill you'll use normally at work, but the secret is no one's good at leetcode shit out of the door. It takes dedicated practice until you can pass it the interviews, just like any new skill.

[gitfan86]

I found that I make the most money investing, mainly via Tesla over the past 8 years. I only have about 1% of the engineering skills and work ethic of Elon, but that has been enough to understand what he is doing and ignore all the people on CNBC with MBAs who don't understand engineering.

[keyle]

This resonates with me.

I'm actually thinking that at some point, no one will be building custom software. Everything will be available off the shelf, as some product, running on some cloud within a few clicks.

So "custom software" developers are a dying breed.

For example, when Jira is down, a Jira "specialist" will tinker and bring it back and look like some guru walking down the mountain of knowledge. Arguably, this person probably wouldn't know anything about SIMD. Yet the SIMD guy is looking for a job, no one cares about that guy. But the "salesforce developers" and "Jira specialist" are permanently employed at very high wages.

[oldsecondhand]

Custom software won't be dead because you can't buy integration off the shelf. And JIRA specialists and similar roles will just eat up more of the potential workforce that could be employed as software developers, so software developers will stay a valuable scarce resource.

[smcl]

I think there are quite a few people like us - I have a different background from you, but I do feel like I'm spread a bit thin and haven't really specialized in anything. The good news for us is that I think it's not the end of the world - it's still possible to deep dive into something and specialize in it, so long as you can find the time :)

[int0x2e]

As another generalist that enjoys occasional (very) deep dives but never gets tied down to one platform/tool/skill/problem set - being a good jack of all trades is it's own special skill, and it is quite rare. Small and medium sized teams really need this sort of person as the mythical "10x" engineer, and in many cases this is a great stepping stone to technical/team leadership, PM roles, and entrepreneurship.

[smcl]

This is a nice glass-half-full way to look at it, which honestly I hadn't considered doing before. I will try to think about things this way a bit more :)

[pjmlp]

Having been coding for 35+ years, I feel you.

[fragmede]

> "Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.

> -Donald Knuth, 1974

[gitfan86]

Just don't forget about that 3% https://www.datacenterdynamics.com/en/news/report-aws-uncert...

[gherkinnn]

I can’t build a fire in the rain, nor can I skin and prepare an animal. But I can buy a slab of beef and chuck it in a pan.

If we’d all be stuck with the very basics, we’d be nowhere. This is why abstraction and specialisation are important.

[scaryclam]

Thing is, if you needed to make a fire in the rain and skin & prep and animal, you'd have a good chance of at least getting most of the way there as you understand the concepts. The problem here is more equivalent to not even knowing what and animal or fire is, nevermind how to do the tasks at hand.

[gherkinnn]

I would starve. As would most. And if I manage to scavenge some food, I’d die of some triviality within a month because I don’t have medical training.

We’re completely and utterly screwed without antibiotics and electricity and farmers.

And I’m convinced that at every step of our species’ advancement through abstraction and specialisation somebody warned of impending doom.

I don’t see how the same won’t apply to software.