The truth I had to unlearn is that coding is a solitary activity, and that coding is the most important part of a senior software engineer’s job. Now I rarely have the chance to code for a few hours straight because if I have enough information to write code then all that’s left is the easy part. The hard part is coordinating, defining the problem, planning for the future, and communicating the current status of the problem. Not to mention onboarding newer devs who haven’t learned the technologies yet.
I hate that this has become the norm. Sometimes, even most of the time, tight clean code and proper data structures and clean smart queries are vital for both cost and performance reasons.
That smart(experienced) people think up how to approach a problem and throw it over the wall to the juniors makes me sad, even if it has become somewhat commonplace.
I was actually offered a position doing exactly that for a rather successful, nonFAANG valley company. Literally 'decide how to solve the problem, then hand it off and never think about it again.' It sounded awful for everyone involved. I'd just write in abstracts and never code, and the coder just codes without thinking a ton. Sounds terrible for both party's growth.
I see software as a form of literacy, and it both amuses and saddens me to hear things like "I used to write code, but since I moved to management I have stopped"
We don't hear phrases like "I used to read and write English, but since I moved to management I have stopped"
It seems sad to note that this "move to management" is now also becoming the "move to senior engineering". This indicates to me some problem with job title inflation - like there are not enough manager slots so the management layer is moving down a rung to senior engineer.
Edit: of course Linus Torvalds wrote more emails than code. Which tends to indicate something.
Consider the manager who tries to put in a couple hours a week helping with filing (as in, organizing paper files). Let's say the filing system is very busy and constantly evolving to meet new needs.
Odds are they're just going to mess things up and annoy the people who do it as a major component of their job. Now, it may still be worth it, to keep the manager somewhat aware of how workers are doing their jobs, but it's not going to be helpful.
You need literacy to work on filing, as you need programming ability to do software development, but in either case it's not sufficient. If you're just dipping in here and there, you'll likely be screwing things up more than you're helping. There's too much context required.
Reading, writing, and programming may be forms of literacy, but if you try to jump in with tiny and inconsistent efforts to help someone write a novel—and I mean the actual writing, not helping them with organization or sales or something—you're probably doing more harm than good. Collaboration is possible even on novel-writing, of course, but very part-time efforts aren't likely to improve anything.
Programming is the same, and that's why once someone gets past about half-coding-half-managing it gets harder to keep helping with the coding, productively. It's not about literacy—the person trying to help with an hour or two of novel-writing a week is literate, after all—it's about context.
I've been a manager for a while and don't do much day to day hands on keyboard coding. I'm still able to help, sometimes quite a bit, but it depends on what the problem is.
If someone on the team is struggling with the gnarly domain specific application logic portions, I will usually direct them to a more senior teammate. I'm more likely to add confusion than reduce it. I'm not in those weeds enough to know how things are changing on a day to day basis. I understand the broad strokes, the roadmap, and where the senior devs are taking things. But I might not be able to tell a dev what the gotchas of their idea really are.
Where I find myself most effective is when I can leverage my experience as a developer in general. I can help them with pros and cons of technology X vs Y, pattern A vs B. I can point out things they might not have been aware of in terms of peculiarities of the tech stack and how it might change things - for instance bugs that are only clear if one understands the details of that standard library call. How to diagnose and debug a problem in an effective manner. How to research a problem.
tl;dr I can and do still talk code and help out my team. But the further one gets from being able to rely on my general experience instead of being embroiled in their day to day back and forth, the less effective I am at it
Not exactly - there are about three things in play
1. You cannot alter a company with code in the way you can with written words.
If we split the compmay-as-a-machine and company-as-people-operating-(in)-the-machine and compmay-as-people-adjusting-the-machine then the difference is more stark.
a company as a machine does run on written (and often unwritten) policies that humans adhere to. More and more now there is code doing the actual machine but but it is rare if ever it is a whole piece - maybe there are whole companies totally automated but so doubt it.
As such a big important part of being a manager - changing the machine to be more efficient - is just not (yet) possible with code. but when it is, managers will talk code and write code.
2. I am not sure where to go with the filing part. Yes in many companies there are so many jobs to get done that anyone getting their hands in and automating anything is a huge help. That person would be making a part of the company-as-machine. good. presumably they would do it ten hours a week to a professional standard.
is it the best way to organise things. No - again torvalds had hierarchical arrangement and hardly ever write code - but that belies the reams of code he wrote as examples, discussion documents, strawman and just test code.
Manager should be writing test frameworks or tools to build the documentation in Japan or whatever
3. The whole "pointing people at someone else who is expert". scream bottleneck to me. Screams that people are in silos, there is not enough brown bag lunches ot other ways to discover / get repeatedly told about how other areas of codebase work.
4. things like weird bugs and effects of the tech stack are great - exactly the sort of thing to put in a code review. Or a code review of reviews (which I think is another good managerial practise)
“Code is a liability”
“Don’t solve problems with code that can be solved in other ways”
“Code is grunt work, I’m an architect”
“Projects fail from people problems, not technical problems”
There’s truth to all of these, and yet the people who repeat them dogmatically are often programmers or managers with ultra inflated titles who write blog posts or emails all day ;)
They probably didn’t even like programming and saw it as a fast track to management.
I’ll take the real programmers who get stuff done, thanks.
If you get developers who get stuff done well - sales people have so many stupid ideas that implementing these would hurt my brain.
Imagine implementing everything that pushy sales people throw at developers.
I only agree that "code is a grunt work" is wrong simplification but picking out which code is really valuable to write is still in my opinion much more important than just slinging out code.
My idea is that there is no "work smart or work hard" - first you have to make sure code to be written is valuable and then you work hard to code it.
> “Code is a liability” “Don’t solve problems with code that can be solved in other ways”
In my experience managers tend to parrot those, but it is almost always coders (technical managers who get their hands dirty still count) who actually knew when a problem can be solved without code in an elegant, scalable, way.
Again IME, when managers are left to their own devices for those decisions it's often "send an email telling users they can just [mis]use feature X for that", or "yeah just install Intercom and support will handle" or "ask users to open a support ticket to perform this feature". Solutions which will often creates more problems for support people, customers/users, non-technical users, or even developers later because often they have have to do something with non-structured chat data.
My impression as well. My thoughts then are usually something like the following questions:
"Oh? Have you really sought out all the good resources and learned from them? Multiple different paradigms? Countless projects exploring ideas? Many different languages, learning their concepts? How come you stopped liking to code? What made you lose liking to make the computer do your bidding? Did you ever really like it? If you did not, did you really go all the way you were able to, in order to explore all the things? Do you really know as much as you claim to know? Or have you been 10 years in the same <you all know what lang here> mainstream OOP job and only feel like your time spent doing the same thing over and over again warants you a senior title and you should move on to management, because 'there is nothing more to explore'?"
I do not usually ask these questions. I rather observe and might indirectly poke for some knowledge. When I do ask some of those questions, I usually get a reply like "Meh, programming language does not matter, it is all the same." -- The usual "I don't want to have to learn more." type of response. There are many variations of this response, for paradigms, concepts, programming languages, you name it. Usually there is some overly broad generalization in it, overloooking benefits, that one approach might have over another, because they never tried or learned that approach and have no experience with it. When I hear that kind of response then I know what I am dealing with.
The person is free to show by their words and actions, that they actually _do_ have that knowledge. Otherwise I will just accept, that this person does not love coding the way I do and that they do not have a drive to go all the way of exploring so many different concepts and things. That's totally fine, coding might not be for them, or they might not like it to the same degree (and they do not have to), or they might not have been as lucky as I was and did get continuously in touch with new exciting things to learn about. Maybe they did get stuck in that <you all know what lang here> OOP drudge and did really not see anything new any longer.
Whatever it is, I just hope people don't simply assume, that just because "they have been coding a in the past for x years", their experience is the same I have. I do not mean in experience quantity levels (years), there surely are many people longer in this hustle than me, but in individual experiences and concepts one gets in touch with, when exploring off the main road. There is so so much to explore and learn about. One can probably learn ones whole life and not have seen it all.
I'd argue more people severely overestimate the need of communication quantity and management roles/responsibilities have inflated everything as a result. Worse, people who want to primarily talk are going to advocate for others to talk more.
Regardless, whoever brings up what GP does is frequently bombarded with the old "communication important" or "soft skills matter" spiel in an attempt to validate the explosion of communicational requirements.
Many big modern organisations are built by bureaucrats whose specialisation it is to create more bureaucracy. Thus they spend a lot of time thinking up ways to measure the work performed from various angles, create reports for their superiors, and find other ways to ride on the work of others to earn their salary instead of doing actual work. This propagates downward and soon everyone (but perhaps the most junior contributors) is working in politics about meta-work, rather than doing the actual work.
It takes rebel managers to go "no, I won't participate in this seventh time allocation study" and instead do actual work to break the cycle.
Precisely this. I've seen every size and type of organisation from single digit employee count up to tens of thousands in huge bureaucracies.
Inevitably, the paperwork becomes the goal, and no amount of pleading with middle-managers will convince them that their job is unnecessary. If they were to believe us, they'd have to quit and become unemployed.
Even in my relatively small consulting org I have to actively fight against the rising tide of overhead.
Just recently I tried to explain to a manager that status reports are not the most important deliverable. That the actual product is, and reporting about it is secondary.
Even more shocking: if the manager was active in implementation -- even just a small part -- they would only need a fraction as many status reports. They could just talk to the relevant people instead.
I strongly believe that you can dramatically improve the productivity of most companies by firing 50% of middle management and using the money to hire more people who actually work on the products/services the company is selling.
I remember reading a thought experiment: after a fire drill when everyone is in the parking lot, the CEO can say,
"Everyone who was in an actual call with a customer when the drill started can get back in. The rest of you stay out until someone dealing with a customer asks for your help."
I imagine a lot of people in HR, marketing, and various other paper-shuffling positions have to stay in the parking lot for quite some time. Not to mention many executives!
> I imagine a lot of people in HR, marketing, and various other paper-shuffling positions have to stay in the parking lot for quite some time. Not to mention many executives!
What matters is not communication, but shared understanding. This is of incredible importance to get written code to actually matter.
One gets the shares understanding through communication. If that is going poorly, more communication is required. So whilst we agree an abundance of communication is a bad thing, we disagree on why.
It's easy to hate on time wasted on communication. Disruption to your process sucks. But it's not wasted time if you don't have shared understanding yet. It's crucial in that case.
>If that is going poorly, more communication is required.
No, you need better communication. Start decoupling "more" from "better". That's the crux of the matter, people trying to bruteforce communication issues by adding more communication.
Most people suck at communication. Including 99% of the people applauding themselves or each other for "great communication". We're not solving these issues layering more communication, that's how orgs die under their own weight. What they need is better strategies and to stop boggling down ICs with redundant bureaucracy, as sibling points out.
If your communication is bad, then you will need more communication to get to shared understanding.
Yes, better communication would also be a great solution. But "if you are bad at X, just do X better" is meaningless advice. Useful advice is either how to fix the problem (advice on how to do X better) or less popularly but often very useful, how to mitigate the problem (advice on how to avoid bad outcomes from being bad at X).
Turns out that more communication is essentially the only way to mitigate ineffective communication.
>Turns out that more communication is essentially the only way to mitigate ineffective communication.
No, it's not. This is the equivalent of saying "if your writing sucks, just use more words". Anyone reading an overly terse, jumbled mess can tell you that's not the silver bullet. Somehow, that is the solution we go for whenever management is involved, until they figure out "oh crap maybe boggling our ICs with bureaucracy is in fact a bad idea". Layering on more communication is not a net positive by default, not even in a world where time isn't a factor.
Heck, we both know most people have neither the mental capacity nor the note-taking diligence to keep up with this all. The system is already showing signs of oversaturation with how many go "what did we discuss again last meeting?"
>But "if you are bad at X, just do X better" is meaningless advice
Several others have already given examples. If you don't have information, stop making 30m-2h meetings when everyone already knows the answer is "we have to do more research", followed by actions such as "make a few quick prototypes and test with the client" or "have the front-facing people ask more questions". Use audio, visual, video media to communicate what becomes terse in words. Use less words and less meetings overall, where possible.
Start thinking about what truly adds value and what is a horrible proxy with near-zero evidence behind it. The default attitude is "never delete until evidence proves otherwise". Anyone looking at Brook's Law can understand how this goes wrong.
I shouldn't even have to explain this. I'm a consumer of the culture, not a producer. The fact ICs have to tell management types how to do their job better is ridiculous: that's management's job to begin with, optimizing communicational processes. I don't expect clients to tell me more than "the product is slow" either, even if I'll take any bit of information they can provide me.
I agree quantity isn't the solution if communication quality is poor.
Communication is more than just talking at people. It's about having healthy boundaries, positive conflict resolution styles, being able to reach a decision quickly and explain it clearly and concisely to others. It'd about anticipating blockers and clearing them, streamlining process to keep things moving, being accountable and presenting security in yourself and your actions even if you might doubt them. But most of all its about listening and letting the team do their jobs.
When you do that, what's going to happen is the developers are going to think they can get away with making it even more inefficient. Not intentionally, of course, but the signal you're sending them is "it's fine if it's slow, we'll throw more compute at it" and that's the condition they will be solving around.
So the next time they choose between flashy feature and fixing a performance problem, they will create the flashy feature. "We can let the hardware acquisition people deal with performance."
It might even look like it works, at first. You get features out quickly and the thing runs almost acceptably.
But then months or years later, you're spending a shitton of compute on performing something that could be done with a couple of pizza boxes. And everyone is saying "well it's too late to change now, everything is designed around a HPC assumption."
And now you're stuck bleeding money on things you shouldn't have needed.
If I sound sore it's because I have lived through it too many times.
You should never, ever solve the immediate problem without looking at what long-term reinforcing feedback loops you're setting up in the process.
You're right! An editor probably reads more than all their authors combined, and provides feedback on what isn't up to standard. My engineering managers were expected to do the same. An engineering manager who does not read all the code and PRs is as helpless as an editor who cannot read. They cannot know who is performing well, who needs coaching, who is all talk but makes a mess, etc. The idea that engineering managers can be excellent but code illiterate keeps showing up, but makes no sense at all.
The sentiment I've seen is that a great people manager who trusts their engineers despite not knowing much about software can still be an above average manager.
Given that the median manager seems to be throughly mediocre, an above average manager even if they can't code or read code seems desirable.
I remember reading about an actual observational study on this -- I think on HBR -- and the conclusion was basically that managers that are technically skilled have much happier employees on average.
Another finding from the same study was that the statements "I feel like my manager can do my job" and "I am not looking for new work" were strongly correlated. (This sounds like the same thing but isn't.)
In other words, you have to be one he'll of a people person to make up for cards stacked against you.
I think either end of the spectrum is fine: highly skilled / can do your job if needed, or not technically skilled at all / honest about it / tracks schedule / delegates all technical authority. The messy middle is where the problems happen.
You can't be a coach and a player. It doesn't work. Having technical skills and being able to make or weigh in on big picture decisions is great. But you have to trust your team to do their job, even if it isn't exactly how you would do it. Does it meet the business need? Does it make sense strategically. Is your team staying unblocked? Are you being reactive or proactive? Are your team members growing and improving?
I must live in a alternate universe. At a previous company, the last two "engineering managers" I've worked with definitely could NOT read code. They did not read PRs, other than perhaps the title and Jira it linked to. Any technical management, including PR and design review, was delegated to the staff or principal engineer(s) on the team.
> We don't hear phrases like "I used to read and write English, but since I moved to management I have stopped"
You surely would hear things like “I used to write research papers but since I moved to management I have stopped” or “I used to write fiction stories but since I moved to management I have stopped” or “I used to write legal briefs but since I moved to management I have stopped” etc. if you talked to people in fields where people’s focused work is writing.
"I used to write fiction stories.." yes but they have not stopped reading and writing english on the job. In fact I bet that reading and writing english is still the job.
Things I think software management should be doing
(besides fighting politics that again should not exist but does because corruption)
- review of reviews (how is the code review process going, i'm on problems, common wins)
- code analysis - hot spots, changing idioms,
- keeping up with rest if company - what code issues / infrastructure / operational / metrics are coming, how do we adjust
I see it more as leverage, the senior who understands good coding style and performance implications is far more useful when they can drive decisions across the whole codebase, instead of narrowly on one small feature. I’ll still take small features occasionally, but it’s more of a way to show juniors best practices so that they can improve the code they write, which is a win win for everyone.
I don't understand this, this is the way every hierarchy work, and how every single job/management role is functioning. It's to solve the problem of communication overhead growing exponentially with larger groups of people. Why does this make you sad? And is it better to have a dysfunctional organisation where people float in and out of poorly defined roles and everyone tries to do everything? Does that really make you more happy? I don't get this emotional take on specialisation.
It is better to have a functional organisation where people float in and out of roles defined by the expectations of others and everyone is capable of judging basic business tradeoffs, yes.
That, in my experience, makes people happier. They get to focus on important problems, help people they know, and develop their well-roundedness as human beings.
I think you might be underestimating the amount of overhead that is added by a heavy bureaucratic hierarchy.
This reminds me of a very interesting comment on the engineering and management practices at Intel [1]: "I often called Intel an 'ant hill', because the engineers would swarm a project just like ants do a meal."
I've seen it happen at smaller scales, great engineers in flat hierarchies without direction might not be the best idea from a business perspective...
Only in a very hierarchical organisation are the lowest levels without direction -- because the higher levels maintain their position by keeping important information secret.
If the important information (market signals, experiment outcomes, financial data, etc.) is made available to everyone, and everyone receives a sliver of training in interpreting it, any group of engineers worth their salt can make responsible decisions in the right direction. (Often much better than a small set of executives would.)
I like the idea, and I've seen it work for teams focusing on a single project/product. What's unsolved for me is how to scale this.
Interpreting data takes time, figuring out a strategy that spans multiple projects and years takes time... not sure this is workable to do individually. I'm all for being transparent with goals, that would be a given for me in any kind of organization - hierarchical or not. But somebody needs to keep up with the ideas of the engineers, customer requests, business goals and changing markets to put everything into an actionable strategy. In bigger orgs this is an ongoing process and requires full-time dedication... It would be really hard (but very interesting) to come up with a process to 'crowd-source' those things from 100+ engineers, skipping the middle-management positions.
Yeah this annoys me to no end how tech people pretend that they have casually invented peace on earth, and act like it's the most obvious thing in the world. "Of course large groups of people simply just get along perfectly and efficiently without any coordination" Yeah right.
It's the people who are dysfunctional who thrive in these environments because they don't have to be accountable, so their issues just disappear, and people who actually function and take their job seriously will burn out and go insane in the chaos.
Large groups of people with a common goal can coordinate within themselves. They don't need to hear "do X, now do Y" from someone else.
And if they do, they can appoint that someone else on their own -- it's how the world's free countries operate, after all; and a country is bigger than a company.
The only reason people think this doesn't work for companies is that they haven't experienced the "common goal" part -- management bureaucracy discourages caring about the common goal, instead focusing on encouraging obeying direct orders.
(And then it goes on to redefine "obeying orders" as "coordination" to prevent anyone from seeing what's going on.)
And if they do, they can appoint that someone else on their own -- it's how the world's free countries operate, after all; and a country is bigger than a company.
That's still a "manager" someone to manager better coordination. The point here is that such a role is required to get work done.
Sure, there are weird things that happen when the manager stops being a bottom-up appointee and starts being a top-down ruler. Heck that is incredibly common. But that does not mean we should do away with central figures that handle coordination. You still need those central figures.
The book "Turn the Ship Around" by David Marquet is basically along these lines. He worked to turn a poorly-performing submarine in the US Navy to one of the best. The gist is that he enabled autonomy and shared vision to reduce the top-down heavy handedness that they were usually used to, allowing for more efficient decision making.
That's a gross generalization, and it is still very hard to conceptualize, but thought provoking.
I've worked under these circumstances before. It's not at all utopian, but I was definitely much happier. And yes, it is a bit cultish, but who cares? I'm an adult and I know it's just a job—If some cultish behaviour helps people who otherwise wouldn't care to know each other work together, then I'm all for it. It just requires transparency.
And of course, that isn't for everyone. I know people who hated working like that and left, and that's totally fine. Just don't be dismissive that there are other ways.
It's not that far off from my experience in a research organization.
We underestimate the commitment of others to helping the organization that pays for their food's success (even though we feel the commitment). Coordination is needed but if you trust and empower the ICs you can communicate a high level vision and then just look out for major problems and opportunities rather than micromanaging the people who are doing roughly the right thing.
It's a model that doesn't work everywhere but it can lead to increased creative output, happiness despite lower wages, less need for middle management, and other benefits to an organization.
Coordination without any kind of hierarchy has N!/2 complexity. That gets overwhelming way to soon.
Have an idea that requires everyone else to change something. N!/2 conversations to have. (Or one big meeting with the same sort of complexity).
Need to change your approach to match what others are doing, gotta make a 1-on-1 connection. If they need to change their approach, they need to coordinate with others, continue for a long time.
If you want any kind of efficiency
You need to have small-ish teams. I'd guess about 10 people. But lets say 50. You need to chunk up work so that teams can work in parallel. You need central oversight to coordinate the teams. This can be just a group meeting of team leaders, but the big picture should not be lost. And you need to make some decisions from this central picture.
Isn't hierarchy standing in for encapsulation here? Companies interact with one another in a coordinated way with neither a hierarchy, nor needing to know what every other company is doing
Is a hierarchy the right way to organise a company?
communication does not have to happen from manager down to lower manager and then manager to reports. Why can't one guy at the top just email everyone (and even that does not have to be top down, answers received from God on the mountaintop but can be part of an active conversation (cf Torvalds).
One way of looking at this is hierarchy works well for an organisation where the people are doing most of the actual work (ie an army fighting). It does not have to be the right solution where the actual work is code that will then do the actual work (ie Google's ad market place is run day to day by the code. when Google makes a chnage then they are to all intents releasing a new company that does things in new ways.
once upon a time you had the same people in the same roles and then turned to them and said you are going to (sell ads) in a different way. the distinction between an organisation and what it does was blurred. but with code there is a clear distinction.
I even go so far as to say that coders are the new managers - managers used to be needed for designing an organisation that would perform.
Considering the senior GIS focused dev at my work: to do what he does, but in the 70s he’d be a VP of a division of analysts and mapping techs. In 2022: he’s a programmer/maintainer on a project.
The co-op ramping up on the same program? Back in the day she would be a senior analyst on the management track under the VP. In 2022: a junior coder we can assign tickets to, with senior dev not as a boss/superior but as a guide.
Computer programs automate business processes that would require large orgs and rigid hierarchies 50 years ago.
>Is a hierarchy the right way to organise a company?
I think so.
I've twice worked as a software engineer for flat organizations (once as a subcontractor, once as a normal employee) and I really, really dislike it. Strong leadership is important.
There ends up being chaos, uncertainty, and a distinct lack of accountability.
Good analogy. Imagine Swift writing a few ideas...guy sees land of giants, land of little people, add some pirates, etc and handing it off to some highschool kid to write! (I don't know why that's the first book to come to mind)
In my career, my most rewarding, fun, but also frustrating times are being handed problems I don't know how to solve, even moreso when it seems nobody had tried to solve it before.
Where would we be if people like Bellard just wrote general ideas, but never any code? Without ffmpeg and qemu, probably.
From my perspective it is to stop loads of stupid code/stupid solutions even way before it is written down as a task on your favorite task tracking tool.
You seem to be arguing into promoting seniors into architects. The GP is arguing into promoting them to management.
If the one hard problem your place has is organizing all the easy problems so they add to each other, turning your seniors into architects makes a lot of sense. And that's a very common situation.
But the GP's motivation for moving them into management is basically that the organization is dysfunctional. That's not a good reason, although it may be the only thing you can do.
I am mostly thinking about technical team lead role which is not an architect and not managerial role.
Team lead does not have time to code most of the time but does code reviews and attends meetings with architects and others and works on aligning stars so things happen. Then also has to stop stupid ideas or propose how to better solve a problem for a customer.
But as I read GP post again it seems he might mean actual management.
A tech lead codes less, but they directly contribute to producing the engineering artifact.
They are an "actual contributor with direct responsibility."
However, all meetings that the tech lead has with people OUTSIDE the team, is communication overhead to be minimized. So a tech lead combines code review, external communication, and direct work on the engineering artifact.
Communication overhead is the problem. Architects, people managers, are all overhead roles. They don't "actually contribute" to the product.
The more strictly define it, it's not actually about the "fulltime role." Maybe the senior engineer doesn't change their job title, but their schedule becomes less about coding, more about communicating.
It's about minimizing the amount of external communication that needs to take place per code deployment.
The degree to which software is solving problems, your analogy is valid.
The degree to which it's mechanical, I have a point.
I'm managing a team right now that's making a simple mobile app. 100% off-the-shelf everything. There is not a single 'algorithm'.
Flutter and Django by the book.
With Django, the whole thing is a giant 'convention' - it's like, there is no 'code'. Just 'templates'.
I can't communicate how much confidence this gives me.
In the areas where the team has to make decisions ... that's where all the problems are.
So for most of our activities, we design features, work out the UI, give it to the designer, review, and hand it off to the devs to actually 'do'. The code is mundane.
This kind of scenario is quite common in software, perhaps more common than not.
I work in a FAANG at this level - but one of the expectations is "you lift the others up around you" rather than just handing out tasks, and the other is "you write the hardest parts of the system".
For me this can be something algo heavy with tight perf requirements, or setting up initial abstractions and architecture - it's a mix.
> I was actually offered a position doing exactly that for a rather successful, nonFAANG valley company. Literally 'decide how to solve the problem, then hand it off and never think about it again.' It sounded awful for everyone involved.
I did that for a while, and it was exactly as awful as you would think. The implementers resented the implication that they couldn't do research and make interesting decisions, and I hated spending my time describing designs instead of implementing them. The design documents I wrote were DOA, since the implementers neglected to update them when they deviated from them. And of course all the normal dynamics of software development (shifting priorities, changing product requirements) were happening at the same time that I was handing off "finished" designs. It was a farce, and I quickly left for a role where I could be hands-on again.
The right way to support juniors is much more fluid, because different people need support in different areas, and you have to give them chances to stretch themselves as well as preventing them from coming under too much pressure.
This is why I've always avoided moving into managing things. I'm a tinkerer, not a leader. I enjoy that and wouldn't enjoy the other. I may have done myself out of a bit of salary over the years, but I'm doing more than well enough as I am and my skills/attetudes/other seem generally respected.
This is also not how to solve problems - at least in my experience. I must write some code, usually completely scrapped, to understand how things will fit together. PoC code is the next stage after white-boarding for me.
This was not how I interpreted parent's comment. I thought they said that the hard part of coding is figuring out what to code. Actually writing it is the quick and easy part.
That's not a senior engineer's job.. that's a job that has scope creeped into many roles: project management, lead developer, project owner and a trainer. Are you doing QA and managing the production servers as well?
That's exactly how we define senior engineer at my company. There's a lot of people able to produce code - even really complex and sophisticated. But you'll waste a lot of time if you're working without proper context and well organized team. From the other hand - you can't establish good context and organize team well without knowledge of what it takes to put requirements into code - therefore most efficient way is to blur a line between some roles.
People who realize that, usually quickly become essential to organization. Rest is typically easy to replace.
It seems like you assume, that they are tasked more than usual, but in reality this the way we want to work, because it's simply better. There are many seniors on the team, so it's not like one is expected to fully cover multiple roles. It just means that you aren't bound to single.
We have nearly zero rotation within senior staff, and some actually came back from other companies, sometimes due to pure frustration with how little impact they had on what's happening within the project. Simply most of the team considers it the way it should work, not additional chore.
About 400k (USD I assume) - where I live you could easily get really nice house with that in less than a year, with zero mortgage and without limiting your daily spending too much.
I'm happy for you if you have ability to earn that, but with such expectations and altitude - no wonder US corps are so eager to outsource to our side of the pond :-)
> About 400k (USD I assume) - where I live you could easily get really nice house with that in less than a year, with zero mortgage and without limiting your daily spending too much.
That's not the way to think about it when looking at leveraged assets. A house where you live.
> I'm happy for you if you have ability to earn that, but with such expectations and altitude - no wonder US corps are so eager to outsource to our side of the pond :-)
Are they? Last time I looked there was a lot of Europeans looking to move to America, but the reverse was exceedingly rare.
Yeah I agree, and the most ridiculous part is that they still have architects, team leads, product managers etc who now really do nothing other than riding the gullible software developer
We don't have architects :-) Most of bigger topics is decided by communicating between seniors in various projects. (it's fully transparent, anyone can see and contribute).
We have some PMs/POs in order to cover communications with customer - there's legal part to manage, market research, and there are difficult customers, which unusual reporting needs that have nothing to do with technology, so everyone is happy to leave it to them.
I feel it really helps being part of the customer meetings from the start, so you have a good understanding of the customer's context and needs while designing and implementing . It also allows us devs to raise potential issues much earlier, which can lead to much better solutions than if it's discovered late in the project.
I don’t know why you think that’s true “in general”.
If you have a team with a senior member it, in general, what would you expect that team member to do? How are they different from the other team members?
They are not senior because they’ve been there the longest. That’s stupid. That just makes them the oldest worker, not the most senior.
I expect them to have more responsibility for making sure the team delivers whatever it is they do.
If the team does tax forms, then they’re more responsible for ensuring the forms are correct, and timely, than say, a junior accountant on the team.
If the team produces code, they’re responsible for making sure the team produces the correct, maintainable code in a timely manner.
If the team is two people, maybe that means “write lots of code”, but if it’s six people, it’s much more likely, in general, to be, making sure the rest of the team is doing the right thing at the right quality. Mentoring. Checking. Meetings. Documentation. Protecting the team from politics.
Why? …because seniority is about responsibility, and if all you do is write good code, you’re not accepting the responsibility for anyones effort but your own.
Obviously, it’s not solely your responsibility; you share that responsibility with the other team members depending on seniority. A team lead, for example, and other seniors.
…but, I don’t care how many years experience you have: 0 responsibility for anyone other than yourself makes you a junior developer.
I say 'in general' because that has been my experience everywhere I've known over the last 20 years.
"Senior engineer/dev" is a title, this is not the same as being the 'senior member' of the team.
In general (as per above) the title is given to devs with about 5 years of experience. It does mean more responsibility, but mostly in terms of being able to carry out dev. work without 'hand holding'. So I would say that a "senior engineer/dev" is simply a dev. who has reached full capability as a dev. Sure you are expected to help "junior engineers" but that's not the same as having leadership responsibilities. It's more like in a cop movie when the experienced guy is assigned a rookie as partner.
In larger organisations (which is most of my experience) "senior engineers" are not the senior members of technical teams, which are "principal engineers" or above.
> "Senior engineer/dev" is a title, this is not the same as being the 'senior member' of the team.
I call bs.
I should probably say, “that hasn’t been my experience”, but I just flat out don’t believe you.
So, let me get this straight. In 20 years, you’ve found that senior developer is the role given to developers who have no responsibility above what a junior developer has, they just cost more?
Rubbish.
It’s a sliding scale; I bet you those senior developers have other responsibilities; code reviews, mentoring, deployments, prod support, ci/cd.
I have never worked in, or heard of, an organisation where senior developers just get to sit around, goof off and write code all day… but get paid a senior developer rate.
Sounds great!
What organisations are these? I want to work there! Hook me up.
I think you’re suggesting that responsibility for team and project management is like a step function; you get none until you’re a principal.
That certainly hasn’t been my experience.
I honestly just have to say I flat out don’t believe that in 20 years at large organisations it has been yours either.
In my experience, you are correct. In the wrong organization, you are eventually given so many "other" responsibilities, that you barely get to do any hands-on development work. You'll be doing code reviews, support, and documentation all day.
> Why? …because seniority is about responsibility, and if all you do is write good code, you’re not accepting the responsibility for anyones effort but your own.
Exactly. Ownership of a certain scope.
This came out not long ago, and I love the graphic.
In my experience it's uncommon to tell people that "senior engineer" is a 'terminal level' because, again, this is usually not very senior at all and you might have issues attracting and retaining talent if you do that. Again, "senior engineer" is a title and although it has 'senior' in it, it is actually not that senior within the organigram of most companies.
You might be correct in that you more accurately describe reality, but it still doesn't make any sense, and you have to do some serious gymnastics with both definitions and language, which just further illustrate what a big problem this is.
Not original commenter but same shoe: the answer is yes and yes. Small companies has their perks and drawbacks :) And my view on seniority is definitely skewed: I would say I expect a senior engineer to handle a large(multiple month) task, rip it to pieces, make a rift out of it and handling out paddles for the other team members while talking through the hard shit with other similar minded persons in the company. I'd also expect correct ballpark estimates.
What I do not expect is the business part - decisions, communication with the client, money stuff. I also don't expect responsibility for all of this on one person - this is where multiple roles comes to play as one person could break it's spline from all this.
That's what I thought at first as well, but I eventually realized that's not the case. The senior engineer is mandatory to be consulted and involved quite actively for all those other roles to function correctly.
You're supposed to deliver value. But your org structure is dysfunctional I'd say you're also supposed to say boundaries and flag when you're spending too much time on things outside your core role
Blurring the lines is a senior engineer's job (though at a larger company, this may not happen until the next level up). It's how they grow the scope of what they deliver to the company.
I would be upset if a senior engineer told me that anything in the path of delivering the final product was not their job. Defining 'job' here as understanding something and communicating/helping address/fix with the appropriate team.
I think the hard part would be equally split between: solving the right problem, ensuring the right flexibility, and making sure the customer actually will be happy.
It depends on tons of factors. Yes there are things besides designing and coding, and they can be harder depending on people and projects, but some strong links to the technical parts are always needed, in the sense that a manager is not an evolution of an engineer. Cutler wrote non negligible parts of NT. Linus doesn't "code" much anymore but still has an enormous technical impact.
Limiting the dichotomy to "coding" vs anything else is really weird because coding is just a part of design, and never should have been considered the absolutely only essential part of software engineering -- and that's the case regardless of your seniority. Otherwise you can as well be considered a kind of secretary with additional specialized skills. Even if you don't recognize the other activities you are still doing them, at least temporarily in your head even when working on a project alone.
And also there are tons of areas where code/design can still be tricky even for highly talented people. E.g. writing a state of the art compiler is not necessarily easy even when the problem has been well defined.
Where I live the worst of this is that one is often expected to be the head of a team as well as lead developer. Sitting in meetings with people talking about personal matters was not the reason I became a developer.
The purpose of having autonomous teams with agile development is to speed up development by defining responsibility between different roles in the team and to give the team a sense of ownership that will enable quick decisions and shorter time to production. Scrum for instance also emphasis the need for protecting the developers from the outside. But in this agile post apocalypse it seems like the result have become the opposite.
Yeah, I keep seeing this enterprisey top-down centralized micromanaging cargo-cult "digital transformation" so-called "Agile" rigid overspecified prescriptive process conveniently ignore the crucial SELF-ORGANIZING TEAMS aspect of the original manifesto.
I'm like him, senior developer at a small company (~80 people total, 15 in software dev) and also do all those things.
Sometimes I am team lead or tech lead for a while, then purely dev for a while, depending on what projects we have and how we are divided into teams at the time.
It's not considered "higher", just a role that the seniors sometimes have.
The only job title above "senior x" in the company is Director.
That's perhaps because it is a very small team but it's highly unusual in larger organisations.
In general "senior engineer" is actually a rather junior level in the overall organigram. 5 years experience doing pure dev. and your title is bumped to "senior engineer" but you're still a 'only' a dev.
Yep. Coding is a team sport. When hiring, think more along the lines like you're drafting for an NFL team. How does the potential hire's talents complement the team's? Will the personalities and the way they work fit with the team's? You ignore team culture at your own peril and that's been true now for decades.
This is corporate software engineering in poorly designed systems. Its not software engineering and is a completely separate job. The fact that its so prevalent doesn't negate that fact.
