Senior Engineers are a thing of the past

future senior software engineering skills: plumbing, carpentry, HVAC, roofing, bricklaying

CSS? Is that some kind of new tailwind framework?

One of the overlooked issues here is training issues. Every company and senior dev wants to complain about skill issues and jr devs who don’t understand the fundamentals, but companies, senior devs and higher education are all responsible for creating that environment. No one wants to train or mentor anymore. Every company expects everyone to know an extremely specific skill set but won’t provide any industry specific training. That won’t solve everything but it would certainly help and start turning the ship around.

The one issue with this is that there’s always another layer. You can’t just say “learn the fundamentals” indefinitely without burning through rabbit holes all the way down into quantum physics. Be a bit curious, but at some point you have to say “this is good enough”. Have some interest but don’t let your curiosity consume you.

The old question, "Do you have 10 years of experience or 1 year of experience 10 repeated times?"

I agree with you wholeheartedly, but I need to see 12 years youtube experience before I can like.

I'm so glad I never did any front end development. Not that the business tier was any bed of roses either. You're spot on with we're building at an abstraction level now where we don't understand the basics. Some people get it and dig in, others are happy to stay at that higher level and never really pick up the knowledge they need to handle more complex development tasks. Everyone just thinks there's a package/library for that. And a lot of the time there is. If it works, if it does what you need, if you don't need to modify it, if it continues to be supported, the list of if's goes on. But that's all somebody else's problem now. I retired a few weeks ago and I'm happy to be out of the game. It's no fun anymore exactly because you don't have the opportunity to dig in and learn those things.

Early in your career it sounds like you also had the luxury of time to solve problems. In my entire career as a software engineer, every assignment feels like it was due yesterday, so your first half baked idea is what gets shipped, never to be rearchitected or refactored. Do you think this difference in our experience is due to time constraints changing over time? or perhaps it depends on the company size?

I think something interesting is that you are basically talking about abstraction. When new developers don't understand the fundamentals that make up the current level of abstraction that they are working with then when problems arrive they often don't have enough knowledge to solve them.

This is a great point. Ideally we use frameworks etc not because we can't implement that functionality ourselves, but because we have done so before, felt the pain points the framework was designed to solve, and then choose to use the framework for reasons of convenience or productivity. For this reason, if I'm training someone, I don't immediately start them at the end point. Rather than starting a new project by importing all of the frameworks and tools which we might use for a large-scale project, we start simple, build things, and only introduce the fancy tools and abstractions *when the pain point they were built to address actually manifests*. This way, their learning journey more closely mirrors the history of the industry itself, and the timeline of different technologies which were introduced. And so they understand more of the how and *why*.

Can't code but the algo brought me here. You have a great way of communicating.

I enjoyed this video. I've been experimenting by myself since 20 years ago, anything, programming, networking, cryptography, even reverse engineering, being from html/css to windows drivers (just because I was interested), Linux/Unix, I've been a programmer and a network engineer as well, I'm no better than anyone but I do believe that having the fundamentals completely covered and then experimenting a lot (just because it can be fun) has give me the edge in many circumstances because I can see the relationship between things. Looking forward to another talk from you.

I liked your anecdotes and past experiences, faced many similar situations over the years, some of them generated very stressful weeks / months.

The problem is zero respect - from "management", from juniors, from other "senior" developers...

I think you're right, but not because people don't want them or can't use them and not because people don't want or can't use junior engineers either. There seems to be no path from junior to senior for most people. If you get really lucky and work somewhere that gives you space and time to grow and the company actually has problems that you will learn something from solving, then you'll do well. If you end up consulting on WordPress sites or whatever then you probably won't. That's really it. Other jobs are similar. You can't become a foreman on a construction site by just installing people's bathroom doors for ten years.

14:36 The issue I have with your statement is that no one knows what a job entails until you get there. Like your plumber example the more exposure a journeyman gets, the more prepared they are for complicated tasks. Part of the journey to Master is set of skills that is industry standard people are required to know to receive that designation. The problem with software engineering is that there is none of that. On top of recruiters and hiring managers don't know how to designate certain standards based on certain levels of experience to adequately assess people.

The best way I can explain career progression is this: I want to be part of the meeting. Do I need to be part of the meeting. Just give me a summary of the meeting.

As an embedded engineer, I mainly use C/C++, Bash, Python3, Assembly. I get massively frustrated, whenever I'm forced to team up with developers that solely use higher level languages. They don't understand pointers, lack networking knowledge, don't understand how (web)sockets work, etc... Most can't even come up with their own logical solution to a problem, without having to use a cheat-sheet with predetermined algorithms they learned at college or university! Their lack of Linux knowledge causes reoccurring dependency issues, but instead of solving their problem by learning Linux as a new skill, they just dump everything in a docker container instead... Some don't even understand the difference between a local LAN IP and a public WAN IP, nor the concept of port-forwarding, etc ... I'm one of the younger dev's at my current workplace, with 7 years of experience. However, I'm the one who has to explain basic knowledge to our senior dev's with 20 years of experience...

Great vid. Working with senior devs who knew internals and how to use different tools outside frameworks to solve issues was eye opening to me, very humbling.

I got to "Senior" in about 3 years. 2 of those years were writing payment services by myself, so I chock it up to that.