Coding as such is seldom a bottleneck to begin with. How many times have you been in a conversation along the lines of "we have every detail of the product figured out, but we need another month for the coders to finish writing the code"?
The bottlenecks are almost always elsewhere. Design, quality assurance and debugging, art assets, localizations, hiring, performance management, you name it. And to be fair, AI can streamline some of that.
I am struggling to understand your perspective. In my existence, the bottleneck is always the coding.
The development team has a backlog that could keep them busy for years. Meanwhile, everyone else -- QA, localization, whatever -- operates at whatever pace the code gets delivered.
Never in my entire life have I been in the situation where the engineering manager said, "well folks, localization is backed up so we've got no more code we need to write. Go home and check in next week to see if we have any work?"
The only exception I can think of might be videogames where the bottleneck is the art and then maybe the testing loop. But gaming isn't representative of software development generally at all.
A fully curated backlog with complete specifications that is kept up to date with current changes in the product/industry? I've never had the privilege of working in an environment like that.
Obviously not every item in the backlog has a full design, for work that might be years out.
But yes, the next few items for the team to work on should always have the necessary specifications to start work. Whether it's UX mocks or a requirements document or whatever. Having that stuff ready to go is a primary job of the PM who manages the backlog.
Obviously the engineering team then has to break it down further into tasks to complete, but that's what engineering is. And you will run into areas that turned out to be underspecified and the PM needs to liaison with other folks to figure out answers, but again that's part and parcel. That's not generally stopping the whole team from work, and teams often work on multiple features at once so even being temporarily blocked on one doesn't keep you from progress on another.
I’ve been bottlenecked by that middle part quite often. A design isn’t finished, we’re awaiting user feedback or testing, specs are done but waiting for sign off from required parties, etc..
I’ve never had a shortage of work as an engineer, but that doesn’t mean that work has always been perfectly optimized to business priorities - there’s plenty of other bottlenecks in the process that are not coding.
Your "coding team" there isn't actually coding most of the time. Sitting down to type isn't the bottleneck, but the work that needs to happen so you can sit down and type what needs to be typed.
I find it is either coding or design but yeah not sure where the perspective of the GP come from, that has not been my experience. I have actually vented with other devs about too many brainstorming meetings, ideas of what to do we are never short on. Maybe where I agree slightly is the devil is in the maintenance, ai can maybe? help with that but i think you will quickly reach a saturation point where you have more than you can manage.
I had a period of time at my last job where the product org was so dysfunctional engineers did in fact run out of work.
Initially I didn’t mind it because my team focused on technical debt, but it pretty quickly turned sour. Having to scrape up “work” for the team of 6 engineers each morning to appear productive to management was dreadful
This story feels inconsistent. Where did the backlog come from?
The developers would have to help with the requirements and planning all the code changes. That implies a huge amount of non-coding work was done by the developers.
> Coding as such is seldom a bottleneck to begin with. How many times have you been in a conversation along the lines of "we have every detail of the product figured out, but we need another month for the coders to finish writing the code"?
And you quoted "how many times" contradicting it.
Yes, the art department plans the art and draws it, but an AI tool for generating art could only help with the actual drawing. The possible productivity improvement directly relates to the portion spend actually making art.
Your department or job-role style view of things doesn't make sense for this conversation.
I'd hate to work at a place where the backlog comes from the PM and the requirements come from a mix of PM and UX. Do you really think your PMs know that much more than your Engineers, Data Scientists, Ops/Business, etc.? This just sounds like something the type of PMs most of us hate, the type who insist on being the main character, would say.
Yes, PM's are absolutely supposed to know that much more about what the customers need. That's their job. They're constantly talking to customers; engineers are generally doing that only occasionally, if ever. They're not trying to be the "main character", but their entire job is to be the point person for integrating all the stakeholders' needs and making prioritization decisions. It's organizational needs, not ego-driven.
Sometimes products are simple and straightforward enough where you don't really need a dedicated PM, but then the lead engineer often just winds up informally taking on the same responsibility, and at some point there's enough success and complexity that it needs to become a full-time dedicated position.
I'm really curious how you've arrived at the perspective that engineers and data scientists know as much about customer needs as a PM, that they learned via channels outside of the PM? I've certainly never worked anywhere where that was the case.
Saying the quiet part out loud. What kind of engineering org outsources this? 80% of engineering is confirming your design works, otherwise it is just LARPing.
My thoughts exactly. Most of my coding is actually writing the tests or coming up with a proper harness to check behaviour of the code. Then of course there's other stuff like operations playbook if you are introducing new infrastructure. I have usually worked in environments where ops, q/a, design, code was the full job. First time I worked with explicit SREs it was a bit weird to give people specific commands to run without an overview of the system.
Every time I hear somebody say a phrase like “art assets” I am humbled, reminded that not all programmers have the same experiences or work in the same environments as I do. I don’t usually think about art assets being a blocking part of the workflow because I work on enterprise information systems.
This is still part of “coding”. It doesn’t make any sense to say you’ve “finished coding” when the program doesn’t actually work as required.
I’ve been aghast to see developers present an unequivocally broken product and try to argue making it not visibly broken is “scope creep”.
I mean, that’s why we argue so much about the best ways to write code: we want to reduce the incidence of bugs and make it easier to correct unexpected errors.
> There's been a strong theme recently here on HN of confusing programming (the act of writing code to meet specifications) and Engineering(the writing of specifications, and the oversight of said process, along with overview of testing).
You're making a distinction that might be interesting in some esoteric sense, but that doesn't exist in the industry. When it comes to software, the architects are also the construction crew. There's nothing to confuse if the terms are effectively synonymous.
Nah. Every company has its lore about what makes a good candidate and they try to test for that. The lore is often rubbish (as in: there's often little correlation between interview performance and on-job performance), but there is still a process and that process rejects most applicants.
> One great piece of advice and informal mentor gave me long ago is that there is no information in a rejection.
I mean, there might be, in two ways. Sometimes, you just mess up in some obvious way and can learn from that. But you also get a glimpse of the corporate culture. Maybe not for FAANG and the likes - the processes are homogenized and reviewed by a risk-averse employment lawyer - but for smaller organizations, it's fair game.
But as with layoffs, there's nothing you can win by begging, groveling, or asking for a second chance. The decision has been made, these decisions are always stochastic and unfair on some level, but you move on. You'll be fine.
I think the point, which I agree with, was that in the typical case of a stock rejection, you don't know if the errors you think you made had any bearing on the decision. Information you get from the process you would have gotten whether or not you got accepted, so it's not from the rejection.
There are cases where the company gives you some indication of why they rejected you but they are rare in my experience (in the USA, mostly for legal reasons, IDK about other countries). Or they give you information in some other way. Some companies will stop and send you home part way through if it's not going well. That also gives more information.
So... how is it useful? You're trading one oracle for another. Either of these oracles can be manipulated or compromised.
I think one could argue that it's more elegant from the point of view of blockchain maximalism. But I don't quite understand the utility in any other sense.
The original ethos was that you didn't want the company ran by MBAs, so you wanted to build your management team by tapping into talented engineers.
Of course, this can backfire in many ways. You end up wasting engineering talent, and as the organization grows, managers spend more time on paper-pushing than on creative work. And there's no shortage of engineers who are just bad at reading, talking to, and managing people.
But the huge perk of management is leverage. If you're technically competent and credible, and want something to happen, your team will see it your way. If you're a random "ideas guy" in an IC role, that's not a given.
> But the huge perk of management is leverage. If you're technically competent and credible, and want something to happen, your team will see it your way. If you're a random "ideas guy" in an IC role, that's not a given.
There are three levers of power in an organization - relationship, expertise and role. Role power is by far the least effective. If you can’t get team buy in for your ideas or they believe you’re an idiot, you won’t get anything done.
A high level trusted IC who builds relationships inside and outside of the team and who is strong technically can work miracles.
At my current 700 person company, I’m pushing through a major initiative that management up to the CTO was at first skeptical about because I convinced them of my vision and I built relationships to get buy in.
I’m a staff engineer.
Even at BigTech I saw L6s and L7s ICs push through major initiatives the same way.
To be frank: it sounds nice, but I don't think that's really true. It's the power of "who's going to decide my promotions", "who is going to advocate for my team and get us more resources", "who approves my expenses", "who is going to protect me if something goes wrong", etc.
This doesn't give the manager a pass if their ideas are objectionable, but if they're credible, it's a huge advantage. Small disagreements disappear and people fall in line behind your vision, get excited about it, and make things happen.
In contrast, in an IC role, you can successfully push for initiatives, but you're always working against that dynamic. The merit of your idea aside, folks might simply feel that you're pushing them in a direction that's less likely to get them rewarded or recognized within their reporting chain. That takes extra effort to overcome.
Being very visibly anointed by some VP helps, but that's tapping into the exec's leverage, not yours. And that approach has downsides; I worked with more than one architect / uber-TL person who were universally disliked and feared. The perception was that they showed up to make your life worse by putting extra work on your plate, without having much skin in the game.
> Being very visibly anointed by some VP helps, but that's essentially tapping into the exec's leverage - an illusion of IC influence.
Of course that’s the play. Even a lind manager can’t get major initiatives through without getting the buy in from their manager. When I was working for startups, the director (1st company I had influence at) and the CTO at the second had been convinced of my idea and gave me the authority to pull who I needed to get it done.
Fast forward past BigTech to where I work now - a third party AWS consulting company, after convincing the powers that be of the market, I had it escalated to be one of the companies initiatives for the year.
But more so in BigTech, promotions aren’t completely on your manager. At least at AWS you had to have recommendations by I believe two or three people one level ahead of you and it had to go through a committee.
From talking to a couple of L4s that I mentored when they were interns and when they came back, they were both complaining about the promotion process even though their manager supported them.
> the CTO at the second had been convinced of my idea and gave me the authority to pull who I needed to get it done.
But that mean those people have the power, not you. Without that formal power structure you wouldn't do so much work trying to convince these people, the formal power structure forces everyone to try to manipulate and work with it, even you.
So it makes it so much easier to do anything if you are that high up person, imagine that was you, now instead of having to convince these people to do it now you just do it.
Power structures exist in any group of size. Companies can choose how formal to make them, but they can’t avoid them.
Imagine instead of having to convince the Director, VP, or CTO to support your good idea, that instead you had to convince 100 out of 700 people to support it, while at the same time, those 100 people are hearing good-sounding ideas from 99 people who aren’t you.
I’d way rather work in the former than the latter.
Eh, maybe at faangs or at the executive level but at non faangs you might not notice a role having power because most roles with the Manager title are no longer actual managers but supervisors.
I had more agency over where capital was deployed as a teenager deciding how many people were going to be on the shift for closing, then I have making over 200k/yr as a Senior Manager.
Any role that has decision making power over where money goes automatically has a massive amount more power than a role that does not
The article is mostly about first level managers. I’ve never had any “manager” that really has any power over raises more than 3-4% or any real control over budgets.
When I was being hired as a strategic hire for startups - and was being interviewed by the director or CTO - I specifically asked would I be reporting directly to them or another manager. I actually refused one job because I saw that the expectations they had from me and how far I was down in reporting structure was incongruous.
Maybe for faangs. At every company I have worked at with a manger title from 2019 to present, this was expected of people with "director" in their title and below.
You are not a manager if you do not get to decide where capital is deployed, without your boss's approval.
For anyone reading this comment, if you think you are a manager, ask yourself this question
"If I decided tomorrow that the company would be better off if I hired someone to do role {X}, can I open a new req for that role without permission?"
If the answer is no, you are a supervisor with less agency than the a Walmart deli leader circa 2010
I've worked at places where the "senior executives" couldn't do any of these things without CEO approval. Even if they claimed to "have budget" for something, it still needed sign off.
There's tons of title inflation out there, especially at smaller firms.
You do not manage if you do not have agency. Modern day “managers” are supervisors making sure their directors or executives management plans are going according to plan, and if anything requiring money or headcount is needed to get the plan back on track, once again the director or executive needs to make that decision.
I was not joking about the roles having less agency than a Walmart deli supervisor. I had more say in how the work was done in that role, than I have at any software company while I had the word “managers” in my title
> I had more agency over where capital was deployed as a teenager deciding how many people were going to be on the shift for closing, then I have making over 200k/yr as a Senior Manager.
But the value of the capital you had sway over as a 200k manager is significantly higher. You have to accept that you won't ever have total agency over 7+ digits worth of both human and non-human capital if you're not a VP/CEO (or a fintech bro I guess).
TLM roles are a trap, but not in that sense. There's no expectation that you do two jobs at once.
It's just a way to ease unsuspecting engineers into management. If you don't suck at management, your team inevitably grows (or you're handed over other teams), and before long, you're managing full-time.
Which means that there are three type of people who remain TLMs in the long haul: those who suck at management; those managing dead-end projects on dead-end teams; or those who desperately cling on to the engineering past and actively refuse to take on more people. From a corporate point of view, none of these situations are great, hence the recent pushback against TLM roles in the industry.
> There's no expectation that you do two jobs at once.
I laughed out loud when I read this. I've never seen anyone at any company in a hybrid tech/manager role that wasn't expected to do two jobs at once. Or at least they felt like they were, which is still the same problem.
80% coding & 80% management for that role sounds about right.
As alternative explanation, even if there's no pressure to do so, the thing is these people came to do dev, and probably enjoyed their job enough to get recognized for their work.
So when asked to split between dev and management, outside of a few exceptions they'll want to do 80% of tech by choice. But the management part doesn't go away of course, so it will still be at least 50% (and 80% if they want money, because that's the part they're actually evaluated on)
Management requires a birds-eye view of the project in all its breadth, and quickly responding to issues, as well as reporting up (proactive stakeholder management).
The job of the manager is to keep the CXOs happy (inform/manage expectations) whilst protecting their own team so they can focus on getting their work done with minimal disruption (isolate).
Coding requires the opposite, zooming deeply into the code and retaining focus.
The job of the IC coder is to deliver (design and implement) beautiful and pragmatic architectures that do what is expected.
I recommend anyone to reject to fill roles where these two are combined into one. Note that this is not a comment about workload, but about irreconcileable differences. (The perfect candidates for each even match different personality profiles...)
I've been a TLM at two big companies and in my experience there was no expectation to do two jobs at once - I did majority of management with very very little hands on coding. More like frequent pair programming with more junior staff, code reviews etc. My last manager told me explicitly when I started - there is zero expectation on you to do any hands on work, you need to make sure your team performs and keeps going in the right direction first and foremost.
I've been in engineering, TLM, and management roles in multiple companies. In terms of output, TLMs are not held to the same standard as full-time engineers at the same level, period. Their engineering contributions are dissected only if their performance as a manager is in serious doubt.
In any role, there are some folks who push themselves too hard, and there is no one to tell them "stop", but that's their choice.
This is true for EMs at my company. They are pretty heavily technical, with full manager responsibilities. I honestly always assumed that's what EMs were.
Usually it means you have to manage people but you have no real input on their career trajectory, and in the worst case, if they need to be fired you do not have the power to do so.
This was my experience in a TLM role - you have to manage down to your ICs but you have little lateral or upward power. You're basically just conveying whatever your manager decides to do with your team, but with all the additional responsibilities of a staff engineer.
In big FAANG-style workplaces, I don't think that middle managers without the TL- prefix have the kind of influence or leverage you're talking about here. It changes at VP level, but ultimately, most of the corporate management hierarchy is just spreadsheet misery.
> If you don't suck at management, your team inevitably grows
Inevitably because why?
> those who suck at management
If higher management can figure out not to put more people under them, why can't it figure out to remove the existing people under them?
> those managing dead-end projects on dead-end teams
If "dead-end" just means "not growing" then that sounds fine. When a company does thousands of things only a small fraction of them need to be growing.
> those who desperately cling on to the engineering past and actively refuse to take on more people
"Desperately cling" is a wild way to refer to someone sticking with a job they like. And if they're a TLM it's not the past, it's the present. Wanting to keep your present job is very normal.
And is the end goal to have zero TLMs in this expanded team? If you're going to pick new TLMs to go under the one you push into higher management, what's bad about leaving them in place and putting someone else above them?
Look, I'm trying to describe reality; you seem to be expecting me to defend it. But briefly:
> Inevitably because why?
Because proven, effective managers are always in short supply, so when you hire new people, or if any of the existing managers leaves, it's the default pick.
Plus, most people want to make more money over time. And on the management track, this means angling for that director / VP role down the line, even if it wasn't your childhood dream.
> If higher management can figure out not to put more people under them, why can't it figure out to remove the existing people under them?
They can, but in big and / or growing companies, performance problems are addressed less vigorously than they probably should. This cuts both ways: neglecting problems is wrong, but cutthroat performance management makes people cranky too.
I mostly found TLM a disservice to people who reported to TLMs. They didn't have to earn a promotion as both an engineer and a manager at the same time, so many optimized for their own engineering promotion and any managing they did was out of the goodness of their hearts.
As a devil's advocate (I don't work in Google or in a similar role) but if the requirements for engineering promotion are similar for technical managers and engineers, while the first have to manage people then this is just how the system is set up. In this case I think blaming the system more than people is justified, and Google decided to dismantle the role for some reason.
I'm surprised this is aliased to char*, not const char*. The benefit of the aliasing is convenience, but the main risk is absent-mindedly passing it to a libc function that modifies the string without updating the SDS metadata. Const would result in a compiler warning while letting the intended use cases (e.g., the printf example) work fine.
The only thing the SDS metadata holds is the string's length. Just like how you'd have to realloc() a regular string before using strcat(), you have to sdsgrowzero() an sds string before using strcat().
Basically, standard libc functions that tamper with the string have the same constraints as malloc()ed strings in terms of safety, only you might want to call sdsupdatelen() after truncating a string.
> Toxic expert here! I hate when blog posts try to teach complex subjects. It's almost always a non-expert doing the teaching, and they fail to do it accurately. This then causes 1) the entire internet repeating the inaccuracies, and 2) the readers make no attempt to do further learning than the blog post, reinforcing their ignorance.
Ask yourself why. The usual answer is that top experts either can't be bothered to create better content, or they actively gatekeep, believing that their field must remain hard to learn and the riff-raff must be kept out.
I think the first step is to accept that laypeople can have legitimate interest in certain topics and deserve accessible content. The remedy to oversimplified explanations is to write something better - or begrudgingly accept the status quo and not put people down for attempts that don't meet your bar.
It's also good to ponder if the details we get worked up about actually matter. Outside the academia, approximately no one needs a precise, CS-theoretical definition of big-O notation. Practitioners use it in a looser sense.
> Ask yourself why. The usual answer is that top experts either can't be bothered to create better content, or they actively gatekeep, believing that their field must remain hard to learn and the riff-raff must be kept out.
This oversimplifies things.
It's sometimes a third option: the topic is complex enough it cannot be digested into a ready to consume blogpost without previous work (reading and practicing), which in turn requires previous work, and so on, until you've turned it into an introductory course.
And that's not gatekeeping or "cannot be bothered to simplify" -- it's a falsehood, a kind of internet new age mantra, that everything can be made simple enough to explain in a blog post. Some things can't. There's nothing elitist about it, since everyone has the mind power to take that introductory course.
> It's also good to ponder if the details we get worked up about actually matter. Outside the academia, approximately no one needs a precise, CS-theoretical definition of big-O notation. Practitioners use it in a looser sense.
The article made some genuinely serious mistakes and the author here (graciously, it has to be said) admitted to being wrong about some things like Big O being "the worst case".
In this cases, maybe the damage could be limited by saying "I know this isn't Big O, this is what some engineers call it but it's actually something different. Because practitioners find useful nonetheless, I will explain it (explanation follows)".
I found the visual presentation top-notch by the way, it's clear some effort was put into this and it shows!
There is a lot of value in explaining the gist of something, even if it's not entirely accurate. In my experience, the cases where even that is impossible are very rare, at least when it comes to practical computer programming.
> Ask yourself why. The usual answer is that top experts either can't be bothered to create better content, or they actively gatekeep, believing that their field must remain hard to learn and the riff-raff must be kept out.
Before asking why, ask if. There are good articles about complex topics, they just get drowned out by bad articles.
I remember being taught how to change the brakes on my car. Was explained very simply, it was easy (or so I thought). So I decided to do it to my car next time I needed brake work. And I did, and a year or two later, my brakes failed.
The thing I was taught wasn't wrong, but it left out important details. There are very specific steps involved in cleaning parts, applying the right lubricant, not applying lubricant, aligning parts, not forcing things, doing the same change on both sides, torque specs, bedding steps. If you don't do them, the brakes just fail again. The person who taught me didn't go over those important yet intricate details - probably because they were taught by a non-expert too.
If the choice is "quit my job to start writing lots of expert content", or "accept the status quo", I choose neither. I have my own life to live. But if during the course of living my life, a wave of inaccuracy begins to lap at my door, I will attempt to stem the tide, in my own way. The toxic aspect, I think, is really just the way in which these corrections are given, and definitely I and others could do better with our tone. But to just give up and not give the corrections at all, I think would be disastrous.
(fwiw, I think HN's overzealous "guidelines" force people to either be toxicly positive or insidiously critical. that's not to say I'm not an asshole, but it's hard to just be normal on this forum without this bizarre culture coming down on you)
As a semi-toxic semi-expert, I think one of the main reasons there is precious little blog-sized content that goes deep is that it’s hard to do. Most subjects, in or out of tech, can go incredibly deep on many, many points.
The more detail that’s included, the harder it becomes to write less. If you ask me to write 500 words on indexing strategies for an RDBMS, I’ll probably manage, but very little will be explained. If you ask me to write 5000 words, there’s no way I’ll hit that target, because I’ll want to explain every tangent, every fundamental, and so on.
The single best blog [series] that manages to pull this off, IMO, is Jeremy Cole’s series on InnoDB [0]. It’s not short taken as a whole, but each article is short enough that it (probably) meets people’s attention spans. I think the thing that makes it so great to me is that it’s written assuming that the reader already understands certain concepts. For example, he doesn’t spend multiple paragraphs explaining what a B+tree is; he links to the Wikipedia page, and then describes how InnoDB uses them.
In contrast, when I write something, I usually find myself assuming that the reader doesn’t have some fundamental knowledge. I usually try to either put it in a section that’s easily skipped, or in a pop-out toggle, but either way, it’s there.
To me, these fundamentals are incredibly important, because a. they’re how I understand things b. I don’t feel that you can operate something to its fullest capability (let alone fix it) if you don’t know how the thing works.
Re: gatekeeping, to me the perfect example is the Linux kernel. Torvalds is notoriously unfriendly, and while you can judge that however you’d like, the man has a massive weight on his shoulders, and letting code in that doesn’t meet his standards threatens that weight. I get it. Then, I also came of age during the RTFM era, so I’m used to it.
It's a bit like the choice between two doctors. One is very polite, spends an hour by your bedside every day, smiles and holds your hand and encourages you not to give up but has no idea about how to interpret your symptoms, has a horribly confused idea of what's going on but can explain that mess in his head to you in a reassuring tone that feels authoritative.
The other doc is morose, doesn't smile, the meetings are brief like an interrogation but he knows exactly what's up, spends the time on reading the literature, case studies, phones up other doctors who treated similar illnesses, cuts you and sews you back at the right spot and hands you the exact pills that will get you on your feet in a few months, but at the same time was distant and cold throughout the whole thing and talked to you as if you were a car in the repairshop.
Ideally, it would be both. Of the two I'd still choose the second guy.
The bottlenecks are almost always elsewhere. Design, quality assurance and debugging, art assets, localizations, hiring, performance management, you name it. And to be fair, AI can streamline some of that.