4 ms·
Unfortunately, junior behavior exists in many with "senior" titles. Especially since "senior" is often given to those 2 years out of school.
by xnx 11mo ago
Unfortunately, junior behavior exists in many with "senior" titles. Especially since "senior" is often given to those 2 years out of school.
- SoftTalker 11mo agoTitle inflation?
- tensor 11mo agoIMO tech suffers pretty horrible title inflation. If you reach "senior" after only two years and "principle" after 5, what is left for the next 20 years? It's pretty ridiculous. But this sort of thing is really typical. The average tenure of someone in tech is probably about 2 years and each year the expectation is to see "big" career progression. Very often "When is my title going to change" is asked literally in the first year performance review.
- jghn 11mo agoThe important thing here is for people to understand that at best titles only indicate relative rank within a company. And even then that's tenuous. Titles are effectively meaningless when comparing outside of a company.
- lokar 11mo agoYou get (finite) periods where several large / influential companies have a reasonably high level of rigor for their own levels, and there is a pretty stable mapping between the companies. One such period seems to have ended sometime around the start of Covid, or a bit before.
- deleted 11mo ago[deleted]
- CodeMage 11mo agoWhat makes this whole thing worse is the concept of "non-terminal" levels, i.e. levels that you're not allowed to stay at indefinitely, which means that you must either get promoted or fired. I can understand not wanting to let people stay in a junior position forever, but I've seen this taken to a ridiculous extreme, where the ladder starts at a junior level, then goes through intermediate and senior to settle on staff engineer as the first "terminal" position. Someone should explain to the people who dream up these policies that the Peter Principle is not something we should aim for. It's even worse when you combine this with age. I'm nearing 47 years old now and have 26 years of professional experience, and I'm not just tired, but exhausted by the relentless push to make me go higher up on the ladder. Let me settle down where I'm at my most competent and let me build shit instead of going to interminable meetings to figure out what we want to build and who should be responsible for it. I'm old enough to remember the time when managers were at least expected to be more useful in that regard.
- lokar 11mo agoYeah, the terminal level, whatever the title (they are just words) need to be the point at which you can handle moderately complex (multi-week) tasks with no supervision. And honestly, this will depend on the environment and kind of work being done.
- SoftTalker 11mo agoIf that's what you're looking for you can find it in academia. Universities have no problem paying people to stay around forever without promotion. Of course the pay won't be great, but the benefits are decent, PTO is usually excellent, and the work environment usually very low stress.
- CodeMage 11mo agoFWIW, I'm starting to seriously consider this as a strategy that will allow me to get to retirement without completely messing up my health due to stress and burnout. That said, there's something deeply wrong with our industry if that's the way we expect things to work. I never felt that teaching was my calling, but I might end up being forced into it anyway and taking up a job that someone with proper passion and vocation could fill. Why? Because my own industry doesn't understand that unlimited growth is not sustainable. For that matter, "growth" is not the right word, either. We're all being told that scaling the ladder is the same thing as growing and developing, but it's not.
- xnx 11mo ago> IMO tech suffers pretty horrible title inflation It began with "software engineer"
- jmpeax 11mo agoDon't get me started on "software architect".
- theshrike79 11mo agoI've had calls with Principal Architects who couldn't code themselves out of a wet paper bag. And according to the company experience chart, they should've been a "thought leader" and "able to instruct senior engineers" My title? Backend Programmer (20 years of experience). Our unit didn't care about titles because there was a "budget" for title upgrades per business unit and guess which team grabbed all of them =)
- geodel 11mo agoIts an epidemic all over in IT departments and s/w industry in general. Nowadays people whose sum total knowledge would be managing some packaged Oracle/SAP software installation are holding title of CTO/SVP/EVP of software organization with thousands of developers. Since they bring a certain cluelessness and ignorance as honor to whole orgs actual technical expertise among engineers could be detriment to one's jobs and career.
- tguvot 11mo agoi am principle architect. last time i wrote code for production was more than 10 years ago. i never touched half of languages that are used in our system in last week I resolved a few legal/regulatory problems that could have cost company tens of millions of dollars in fines/direct spend/resources and prevented few backend teams from rolling out functionality that could have negative impact on stability/security/performance. I did offer them alternative ways to implement whatever they needed and they accepted it
- rglynn 11mo agoHow many civil engineers or architects know how to put up scaffolding or lay bricks? That was a little tongue in cheek, but I am genuinely curious what you think the correct approach is? I have seen many teams that do need to have someone overseeing the overall architecture, even if that person isn't writing the code line-by-line. If you have that capacity baked into "Backend Programmer", then great, but not every team is the same. Is there something inherently wrong with an "architect" who hasn't written code in a decade but is instructing seniors? One might believe that the answer is self-evident, however, I would argue that the organisational structures we see in the world (functional or otherwise) do not bear this out.
- 9rx 11mo ago> If you reach "senior" after only two years and "principle" after 5, what is left for the next 20 years? There is nothing left. Not everyone puts in the same dedication towards the craft, of course. It very well might take someone 30 years to reach "principle" (and maybe even never). But 5 years to have "seen it all" is more than reasonable for someone who has a keen interest in what they are doing. It is not like a job dependent on the season, where you only get one each year. In computing, you can see many different scenarios play out in milliseconds. It doesn't need years to go from no experience to having "seen it all". That is why many in this industry seek management roles as a next step. It opens a new place to find scenarios one has never seen before; to get the start the process all over again.
- Yoric 11mo agoEr... I've been programming since I was 7 and I'm old enough to remember the previous AI summer. Somewhere along the way, I've had impact on a few technologies you have heard of, I've coded at almost all levels from (some very specialized) hardware to Prolog, Idris and Coq/Rocq, with large doses of mainstream languages in-between, and I don't think I'll ever be close to having seen in all. If anyone tells me that they've seen it all in 5 years, I'm going to suspect them of not paying attention.
- 9rx 11mo agoThe scare quotes are significant. Obviously nobody can ever see it all as taken in its most literal sense. But one can start to see enough that they can recognize the patterns. If your job is dependent on the weather, one year might be rainy, one year might be drought, one year might be a flood, etc. You need to see them to understand them. But eventually you don't have to need to see the year where it is exceptionally rainy, but not to the point of flood, to be able to make good decisions around it. You can take what you learned in the earlier not-quite-so rainy year and what you learned during the flood year and extrapolate from that what the exceptionally rainy year entails. That is what levels up someone. Much the same is true in software. For example, once you write a (well-written) automated test in Javascript and perhaps create something in Typescript, you also have a pretty good understanding of what Rocq is trying to do well enough to determine when it would be appropriate for you to use. It would no doubt take much, much longer to understand all of its minutia, but it is not knowledge of intimate details that "senior", "principle", etc. is looking for. It is about being able to draw on past experience to make well-reasoned choices going forward.
- neighbour 11mo agoI'm sympathetic to the title inflation issue but more on the problem of the "engineer" title, not to mention the "scientist" title. For example, I work in Data & AI and we have: - data engineer - analytics engineer - data scientist - AI engineer What I don't know is what's the alternative? Data Engineers are basically software developers. Analytics Engineers were Data Analysts or BI Analysts but the job has changed so much that neither of those titles fit. My opinion is that basically everyone should just be a "Developer" or "Programmer" and then have the area suffixed: - Data Engineer → Developer (Data Infrastructure) - Analytics Engineer → Developer (Analytics) etc.
- theshrike79 11mo agoA coworker had this anecdote decades ago. There's a difference between 10 years of experience and 1 year of experience 10 times. YOE isn't always a measurement of quality, you can work the same dead-end coding job for 10 years and never get more than "1 year" of actual experience.
- joquarky 11mo agoExperience is knowledge of what not to do.
- theshrike79 11mo agoIt's the old saying: "$10 for the part, $990 for knowing where to put it" You get a feel for what works and what doesn't, provided you know the relevant facts. Doing a 10RPS system is completely different than 300RPS. And if the payload is 1kB the problems aren't the same as with the one with a 10MB payload. And if (when) you're using a cloud environment, which one is cheaper, large data or RPS? It's not always intuitive. We just had our AWS reps do a Tim "The Toolman" Taylor "HUUH?!" when we explained that the way our software works is 95% cheaper to run using S3 as the storage rather than DynamoDB :D
- wseqyrku 11mo agoTrue. I remember myself spending weeks just to figure out what not to do next because I can't afford a redo.
- stephen_cagle 11mo agoYou know, this is kind of a funny take at some level. Like, for any surgery, you want the doctor who has done the same operation 10 times, not the one who has 10 years of "many hat doctoring" experience. I'm not really arguing anything here, but it is interesting that we value breadth over (hopefully) depth/mastery of a specific thing in regards to what we view as "Senior" in software.
- lokar 11mo agoYou want the Dr who has done the operation 10 times, and learned something each time, and incorporated that into their future efforts. You probably don’t want a Dr who will do their 11th surgery on you exactly the way they did the first. This is what that saying is about
- 3acctforcom 11mo agoTitles in of themselves are meaningless, I've seen a kid hired straight from uni into a "senior" position lol
- abustamam 11mo agoI've job hopped a bit. I've gone from junior to senior to lead to mid-level to staff to senior. I have ten years experience. My career trajectory is wild. At this rate I'll be CTO soon, then back to mid-level.
- Alex_L_Wood 11mo agoIt also doesn’t help that definition of who “staff engineer” is varies wildly by the company.
- farhanhubble 11mo agoAbility is a combination of aptitude, skills, persistence, and exposure. More importantly, intention matters and it show up in the quality of your work. If the intention is to cut corners, no one can stop you from doing shoddy work. Number of years and titles do not matter much if the other parameters are low. Aptitude paves the way for exploration: learning languages, paradigms, modeling techniques, discovering gotchas and so on. Skills follow from practice and practice requires a tough mindset where you don't give up easily. So many software engineers learn to code just to pass exams and interviews. They claim they have strong logical reasoning. However, they have only been exposed to ideas and patterns from competitive programming rut. They have never even seen code more complex than a few hundred lines. They haven't seen problems being modeled in different languages. They haven't had the regret of building complex software without enough design. They have not had the disappointment of overengineering solutions. They have never reverse-engineered legacy code. They have never single-stepped in a debugger. All they have learned is to make random changes until "It works on my machine". Yes, software is complex, disposable, ever-changing and often ugly but that is no excuse for keeping it that way.