One of the main reason I have come to to make peace with that, is that these companies are not optimizing for delivery and product quality first.
They are optimizing against risk (of change, of loss of control over the whole process from ideating to selling/shipping).
If you can build the product/service in 2 months with a tight focused team of 3-5 people, in a 100+ engineers company, how do you manage if this 3-5 people leave (whatever the reason): how do you manage to infuse their experience/expertise over the thing they built, to 10/20/30 other people to mitigate then this risk?
You can manage to do so when your company grows, because... you don't have a choice, you started small.
When you've grown already, to mitigate this risk, you have to start to infuse things across many people and layers of people you have, so that when, 3-5 people leave, it's almost barely noticeable an event.
Maybe there's a better set of reasons. But this one made me understand better the whole world of big corporations and especially (big) consulting sofware companies (which are often several ones contracted on the same big projects).
Edit: you may also understand "optimizing for" as "scared to death about".
That would be justifiable if the risk was proportional to the cost. Frequently it just isn't.
As a case in point, if "when, 3-5 people leave, it's almost barely noticeable an event" then you've almost certainly over-compensated for the general case. Why? Because the entire set of people who know anything about a given project simultaneously leaving should be incredibly rare. If that's your benchmark event probability, and your risk mitigation costs are linear in the risk probability (which they probably are, by vague handwavy analogy to finance thinking), then you're constantly bearing costs that aren't justified by the downsides you're likely to encounter unless the specific project in question is company-breakingly critical.
If an entire dev team up and leaving isn't a rare event, you've got deeper problems.
This incredibly rare event has happened at almost every firm I've ever worked at (except small startups), multiple times a year (different teams/products, but sometimes also the same product with its new team)...
Yeah they should fix the actual issue many layers above, but that's not something the guy planning for this can do at huge corporations. You just deal with whatever it throws at you.
I think rather frequently the impact of such a "rare" event could indeed be company-breakingly critical, depending on which part of the company that team was running. As a thought experiment, if all DBAs left tomorrow and the database fell over the next day, how much time would the next-most-capable person need to figure out the backup policies and scripts, restore the db and bring everything back up? I've personally seen this sink a company outright. It's only anecdotal evidence ofc, but it is still something that happens.
Worse, people leaving a team are not independent events. People leaving a certain team is often highly correlated to other people leaving the same team, because there is some common cause like a toxic manager.
"should be incredibly rare". Not incredibly, it's rare, but it happens (seen it in two small companies, it killed them; saw it in several ESN/consultancy projects, it killed the contract, but was a manageable event in the whole company; saw it in medium software companies, it killed the projects and sometimes pushed for strategy changes).
It happens enough for many (not all) individuals to have noticed across their career (especially when in management, where a big part of their role is already to manage risk).
It happens enough for any single company to be quite traumatized by it when it happened, and to try to avoid it in the future.
Where some companies do it differently is: they don't overreact, they understand that this is a risk management issue and that you can balance it, and/or they don't setup a "general case" for all projets/teams (depending on the type of the project). This requires quite some serenity and perspective.
In most of the large companies I worked for there was zero documentation (+1000 employees, +100 engineers) or very very little or only in a few projects. When people were leaving, someone else was getting hit with a shitty undocumented project, they would spend some time learning it - and that was it.
In the worst case a doomed-to-fail-rewrite started and troubled the team for a couple of years.
I think the main issue is that:
- People are given tasks from the board of directors (trickling down layers and layers of management), they don't feel like it's their problem
- There is little accountability, tracking performance is very hard; tons of companies don't bother, but some of them do (after HR intervention, CTO being in trouble justifying the costs) and they can't find decent metrics to use for performance, so the bosses are basically flying blind / trusting middle managers.
- No high growth stocks that will make you rich
- Middle managers feeling like they need to prove they're doing something imposing weird and useless rituals: meetings, presentations, etc
These factors allow people to slack off as much as they can and take as long as they can to do anything.
As long as they can come up something for standup, it's all good.
This does not look like disagreement to me, but rather a distinct perspective of the same thing (was it the issue, or the symptom?).
Getting hit with a shitty undocumented or doomed to fail project is part of the problem/risk being managed or not: on some occasion, it can kill the team/project/company, on some other, it can be managed more or less successfully, but still in a way that is _not regular_ against the baseline.
When you get a project handled by a larger team of people apparently doing "not much", 1/2/3 of these leaving will not change the baseline of the project they were working on (or if it does, then comes the pressure to reorganize again to avoid that disruption).
1. a unicorn where someone implemented a a CI/CD system that none else can work with nor comprehend
2. a public institution where dozens of people work against the clock to replace the software maintained by a few old farts close to retirement
3. a critical financial institution where secrecy and nepotism made anyone with 30+ years of service into a major failure point.
IMO, the bigger the organisation, the more they are shifting from internal risk management to outsourcing all risk. When the risk is handled by third parties via contractual obligations, life get easy for middle management.
Needless to say, many of those contractual obligations are not worth the paper they are written on. Many organisations survive largely on the good will of the lowest-rank employees.
The sad thing is that it’s a joke that many people don’t seem to be in on.
You get all these defenders coming out of the woodwork when people wonder what the hell all the programmers at say, Twitter, are doing. Supposedly you puny mind can’t comprehend the challenges of developing a website “at scale”
The real answer is, almost nothing. People are being paid very high salaries to do nothing.
Nah, most people feel some guilt at doing nothing when they're paid well, so my guess is lots of internal projects that don't go anywhere and that we never hear about. That's quite different to nothing at all.
> The sad thing is that it’s a joke that many people don’t seem to be in on.
On each of my job in my early career, I spent considerable effort weeding out people who got too used to such mode of work.
There are software developers with vastly different prior work experience, and expectations. People who do 30 minutes of actual coding a day, and ones who do 11 hours in coding sweatshops.
People who spent their entire career on 30 minutes of coding a day jobs, and think of themselves too much once they rise in seniority are the worst, and are the biggest source of dumpster fire/death march projects.
My third serious job in Canada: work in a consumer electronics trading company, upgrading their shipping system to get shipment status from DHL API, and submitting new ones. My predecessor, and ex-unit head wasted close to $1m, and more than a year, got SAP involved, invited many consultants, change managers, a project management contractor, and just been in the process of "fixing deficiencies" of his work by buying "enterprise SOA solution."
23 year old me called this bullshit on the second week, fought to have a serious talk with the company owner, rewrote a 10 years old steaming pile of PERL, and BASH scripts to Python, Postgres, and JS frontend in under one week, showed it working, and countered "You don't understand SOA!" protests of the unit head in front of the boss. He gets fired, I get a bonus the size of my annual salary.
Since then, my bosses always threw me as a "firefighter" on projects in crisis.
------------
We now have 2 major trends in the industry:
1. More, and more non-IT companies are trying to do software
2. A giant amount of newcomers to the industry who would've normally went working for banks, and management consulting companies eroding big IT companies as later grew with little regard to quality of hires.
How do I get in on this? For the 10 years I've been in this industry I've never been in a job where I felt like I had it easy. It's always been a rush to get one project done then there's always something else in the pipeline. Whether those projects are actually worth doing is a different question...
Become a contractor or even more so a consultant. You'll often find yourself on dysfunctional teams where management barely knows what they want and things often never get done.
I wouldn't recommend it though since it's soul crushing.
Manager pay correlates with how many reports they have. So all of them are incentivised to making it look like their team is spread thin, so even if you don't have to work hard he will make you work hard so that he can tell his manager that he needs more headcount.
Careful what you wish for. It's not "easy" at places like that. It's just different. Instead of your work being keeping a system up and running putting out fires or implementing features or coming up with algorithms on a tight schedule... it's, instead: figuring out who is doing what, what you're supposed to be doing, what permissions list you need to be on in order to access X system, asking to be on that list and waiting, submitting a minor feature to code review that takes a week to go through because someone didn't check their email, rewriting a major part of the code in that review because someone came in at the last minute and didn't like some thing about it that was actually decided on weeks ago but they weren't looped in.
The amount of actual lines of code written by an average SWE at a BigCorp is miniscule. The amount of churn and spinning and hand wringing that goes into that code is staggering. But it's like that for a reason. There's just a lot of people.
It's torture, and in order to maintain productivity you need to have about 5-6 of these processes running concurrently, and it's why you get paid a lot of money to do it.
Do poorly at juggling that and making "progress"? Find yourself on the receiving end of a performance review where the label "meets expectations" actually means "you better start kicking ass at this, or you'll find yourself with no stock refresh grants for next year."
All the money and free food and so on is just a salve to try to make the whole thing less unpleasant. Some people get a high out of the process, while it drives other people slowly crazy.
(In my last months at Google the only part of the job I "enjoyed" was the week I was on-call for the first time on my new team. Because it was the only time in over a year where I felt useful even though it was quite stressful. That's how I knew it was time to pack it in)
It might sound exciting but its actually super depressing. You get paid mad $$ and in ur head ur think "what the ef are these idiots paying us for?". I ended up leaving just because it made me feel so useless i couldn't handle it anymore.
They don't have it easy either. They have to demonstrate at least once a year that they've "accomplished" something in spite of an entire organization of gates that make accomplishing anything nearly impossible. But they still have to figure out a way to do it, and it still has to be somehow represent enough to justify their pay.
There's scale, and then there's _scale_. And I can happily believe that Twitter is working at the latter.
It's like something like AWS or Azure. You can provision and deploy a K8s cluster? Awesome! Now, can you do that consistently for the next 100 thousand K8s clusters you're selling to your clients?
I think regardless of scale, spending over a year working on edit functionality is endemic of something being horribly wrong organizationally. Maybe it doesn't even involve the software engineering groups (though it probably does). But that's simply not something that takes even a fraction of that time in a healthy organization.
That's what I am thinking. E.g. I am looking at lichess which has a massive user base and is developed by one full time developer and a few dozens volunteers. Twitter is obviously bigger, but I simply don't buy that you need more than 7000 people to run that site.
Maybe you don't need 7000, but software is even worse than icebergs (Only 30% visible). How many people at Twitter are there to fulfill functions we aren't even aware of? Compliance, privacy, legal, internal tooling, etc and god knows what else.
My experience at a tech company with around the same number of employees is that it actually feels understaffed in some of the areas I've seen. It's surprising how much responsibility some teams have.
The whole reason it feels understaffed is because there's too many people.
I know it sounds counter-intuitive, but software doesn't really scale linearly. Unless they're 100% independent, the communication overhead will always be there. Fred Brooks and all that.
With 7000 developers working in a connected system, it probably feels slower and less things get done than if there were less people.
It's not simple to go back to having less people, however. The architecture is most certainly tied to the organizational structure (Conway's Law), and firing people will make it worse in the meantime.
Please elaborate. It doesn't feel understaffed because of communication overhead or being in a connected system, but because of the level of responsibility (I.e. critical system) or product surface area a team is responsible for.
Sure. The things you mention (Compliance, privacy, legal, internal tooling) also have to grow together with the number of developers to scale. Not only those, but also support, QA, management, UX/UI. All those ares have to increase when the dev headcount increases. But since most of those need some degree of centralization and coordination, they can't escape communication overhead and orgs slow to a crawl.
Also, software development teams have to assume more responsibilities just to escape this communication/interconnection overhead: devops is a good example, you no longer have to depend on another team, but now you gotta do operations yourself. An example of avoiding interconnection overhead is having isolated services: now you don't run queries on team Y's database, but you still have to maintain that data on your own DB. Isolation is a good alternative, but it also has its costs.
Unless we're talking about 7000 software developers working on 400 completely different and completely isolated products and answering to different people, there's gonna be a lot of invisible communication overhead, or overhead because of the need to work together with the other 6999. We developers tend to abstract it as being "part of the job", even though it is definitely non-essential complexity.
Even consulting companies doing different projects can fall prey to that: I know lots of cases of internal frameworks/libraries/UI-toolkits being adopted to accelerate development, but they ended up being a bottleneck in development because the team that owned had a full backlog.
Honestly why I'm considering not starting my own business. Getting the product to work is the first 80% of the work. The remaining 96% is billing, authentication, and marketing.
I have been an independent consultant for almost my entire career - working with clients large and small, mostly on solo projects.
Took a FT job at a megacorp a few years ago and assigned a new project - I read the specs/requirements and in my IC mind thought to myself - if I was hired as contractor to develop this tool, how much would I charge? and how long would it take me? - and came up with 1 person, for 2 months, and would have been delighted to be able to bill $40K for it, but probably would have went it at $60K on a fixed bid (I always preferred fix bids).
Of course this wasn't a project I was bidding on, I was just the lead dev - the company pulled together a team of almost a dozen people and a budget of just over a million dollars with a 8 month timeframe to get it done - they also budgeted another $120K/year to host it when it was done on multiple big servers in the internal data center.
We spent the full million dollars and got it done - I did however have one small win and pushed them to micro-services solution in S3 and Aws Lambda and got the whole thing to run within the free-tier of an AWS account.
If you ever start a small software company, don't ever hire people that have only worked in large enterprises - they just don't know how to get things done cost or time efficiently.
Companies like twitter operate at a different scale. Lichess can off load hiring devs by using out of box solutions like paying for AWS, paying for cdn, using adsense to serve ads, utilizing thirdparty libraries, etc. For large companies, a lot of these are in house solutions, because at that scale, it could be cheaper, they wont as dependent on other companies for reliability, they have more control over where the data is being used or stored. etc.
It is funny because people who are unemployed are shamed for being "unproductive members of society", yet when you get out into the real world, you see all of these people doing nothing and getting paid lots of money, which is even worse than being unemployed in that context.
Anyway, it seems there is just a lot of money to go around and political and social favours dominate a lot of the decisions.
Free market communism as in? Free market economy with communist political system and allocation?
Trying to parse your definition of the term, as it seems like any definition for communism disrupts the feedback mechanism that is a free market's primary (only?) advantage.
It's a free market but with the financial incentive system removed, but maybe social/status/religious incentive retained. Everyone does what they want but at 100% tax rate and the product is shared. Of course this only works in IP because it has zero marginal cost of consumption (and taxation!). In meat space you have the political problem of how the fruits of labor are distributed.
Who pays the developers of said software so they don't starve? The state? Then the state will decide what projects gets traction, such centralized planning is the main reason communism fails. Software engineers would then be more like scientists having to spend most of their time writing grant requests to motivate why they should get any pay, I really doubt this would give society better software compared to the current free market solution.
you could have a ubi system and then add incentives for devs on open source products that are used. Just a thought, I'm sure there would be corruption of this system too
Not all communism is authoritarian/statist. "Libertarian communism" (sometimes known as anarchy) is socialist while allowing freedom of association and economic self-determinism. Historically, it has been strongly linked to the concept of republicanism and unions.
What part of it is most socialist? (Honestly asking and curious, I'm terribly ignorant in the more niche -isms of potential political-economic organization)
It's socialist in the sense of promoting mutual aid and communalism. The union movement was originally very influenced by these ideas. Unions, co-ops, FOSS projects, and community organizations are good examples of these type of political/economic structures.
If you're interested, Peter Kropotkin wrote a lot of books and pamphlets that are freely available.
This ongoing debate on productivity at small startups vs large companies will never be resolved by argumentation. But as we can see from this thread, corporate engineers overwhelmingly outnumber early-stage startup engineers. Therefore, they tend to "win" the debate by being louder.
The other thing about big corps is that they work on stuff that actually matters to customers for a long time, not "Our Incredible Journey" demo software intended to be rug pulled as soon as the founders get acquihired.
With an addendum: it's not that they do "nothing", and that's the "problem". The end result is minimal, but the amount of work is still significant.
In any saner place it would amount to almost nothing, but for certain companies it is an Herculean task. And developers know it.
However due to the fact that the company hired thousand of coders, their communication overhead is now too massive. Their architecture also suffers due to the needs of handling those thousands of developers, so there's also a lot of work to be done in coding.
But the pressure is still there. Why hasn't your team changed the color of the button yet? "Why is it so hard?", "Why is it taking so long", etc etc
> People are being paid very high salaries to do nothing.
I'm patiently waiting for some kind of deep-dive historical monograph to be written in the 2050s. What I suspect may have happened is that these companies overhire top talent simply so their competitors can't have them. For the actual work they do, it's massively overpaying. As a strategic investment to prevent said talent from working elsewhere or starting their own business, perhaps it pays off.
I think it is like brand name vs off brand. I just bought off brand oatmeal that was $1.98 vs the brand name was $3.50.
Someone buying the brand name is just operating on an unthinking heuristic that they only buy "the best". I am sure they would justify it after the fact that the brand name taste better even though it is just oatmeal.
So many decision points in society run on that heuristic IMO.
As I commented elsewhere. They're not doing nothing. They're maintaining the organization. In a large company with a service that needs to be reliable, doing things quickly can result in things... breaking quickly and causing headaches when there's no consensus, etc. So everything needs to be done slowly and carefully and looping in dozens of people even for small trivial things. It sucks working this way, so they have to pay a lot for it.
Yup i recently worked at a company that had a lot of their base technology already built out. They hired a lot of new expensive talent and the talent was pretty bored so they made a big project to re-do all the existing technology that already worked pretty well.
The results are less than good..
> People are being paid very high salaries to do nothing.
People are being paid very high salaries to be frustrated by explicit prohibitions on doing anything. Nobody gets to being good enough to be hired by a company like Twitter if they don't actually want to do real software development - management exists to crush that desire and ensure that nothing ever gets done.
Astonishing to me that someone with 20 years' experience in any industry could have so little perspective. Obviously there are inefficiencies with big companies, but complaining about needing to do documentation, or basic project management?
The writing is smug and shows no self awareness - it seems to me that the author cannot recognise that there may be other priorities than exactly what is in front of them and therefore everyone who disagrees with him must be wrong.
It is good that the author has found something that suits them better.
I'm pushing more than 15 and feel like the author is right.
What you're missing is that doing soft tasks is a tradeoff and big companies are leaving a lot on the table by having an inflexible culture.
Those same big companies will end up buying startups for 10x their ARR to get some mediocre product with no documentation or tests, cranked by developers on redbulls swearing at each other instead of doing retrospectives and yoga friday.
I understand the trade off, and big companies do too. You're going to lose a lot of very talented staff because that is the work environment doesn't suit them. It is a trade off companies make because they are managing risk, and because they have other priorities than having software coded at the fastest possible speed.
> Those same big companies will end up buying startups for 10x their ARR to get some mediocre product with no documentation or tests, cranked by developers on redbulls swearing at each other instead of doing retrospectives and yoga friday.
And yet, that mediocre product still is orders of magnitude better than what the big-co would have been able to produce internally, simply because of all the ass-kissing and butt-covering involved in big-co office politics.
Yeah, it's a strange article. They seem to miss the underlying point that in a business, generally speaking, writing the code is relatively easy. It's working out what problem you're trying to solve and who you're solving it for that is the hard part (an the bit that requires you to spend time talking to other people). Of course you write more code working on your side project, because you know exactly what you want to do with it and there's usually no consequences if it goes wrong.
The problem with the article is that it's the perspective of an engineer who hasn't had to think about higher-level problems. If I had to summarise their perspective it's "if engineers are writing code, that's a good thing, and anything else they do is probably a waste of time".
But what if engineers are writing bad code? What if their code doesn't solve any customer problems? What if the other thing they're doing is helping them write better code? Or scaling the company so they can hire other engineers who do write better code?
We've figured out 20 years ago that writing code, showing the resulting program to customers and getting feedback was the most effective way to find out if you're actually solving customer problems. Some group of people wrote about it in something called the "Agile Manifesto" or some such.
Considering how companies are implementing the "Half-Arsed Agile Manifesto" rather than the actual "Agile Manifesto", I think reading this article might be what pushes them to jump off a bridge. 20 years of companies failing to understand your 4 line text, and using it to justify things that are utterly antithetical to what it stood for, has got to hurt. It's so simple:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
Sounds like an environment the author of the post would like, he even describes such an environment later on, one that he enjoys so much he overworks for no extra pay.
Then there's the twelve principles, one of which is:
"Working software is the primary measure of progress."
Another one is:
"The best architectures, requirements, and designs emerge from self-organizing teams."
Another is:
"Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done."
Following bullshit company processes and pointless meetings is the opposite of the above. The one that might be contentious is:
"Business people and developers must work together daily throughout the project."
This sounds a lot like meetings, but that's the smallbrained take on it. Here's an easy alternative: Continuous Deployment in a staging area and a Slack/Teams channel for business people to comment on changes they feel are necessary. Not only does the request get recorded (often nothing gets documented in meetings) but the communication is asynchronous and doesn't require booking the entire team for hours.
The discussion is also a lot more actionable because it is about something concrete.
Given the above, what do you think about how an author of the manifesto would respond?
I imagine the author of the original article works in a company which is prioritising the right hand of the principles over the left. We've all worked there, we've all hated it. I did, so I set up my own company where we'd do agile right.
Hired my own team of devs. Got no revenue, velocity was low. Ended up annoying all the devs by trying to push them to spend more on the right-hand side of the manifesto than they thought was necessary so I could figure out why nothing was getting done. Still got no revenue. Eventually gave up.
I think the authors of the agile manifesto would say that building complex software requires the business to adopt agile (real agile, not half-arsed agile) with the tech team subsequently following it. The engineers also need to deliver on their side of the bargain. That means continous value, and not just fiddling with shiny new tech and fancy design patterns. When both sides of that operation work well together, you get good software. If you've got enough good people that already know how to do this, it bodes well. But how do you find and pay for all these good people? That's why you get people that merely think they're good, but are at least much cheaper.
The engineering tendency when given freedom is to over-engineer everything, leading to disappointed clients, and a fragile system that's buggy and can't be fixed. It's one of the big reasons so many tech-led startups fail, and also why bigger businesses end up putting all these bullshit processes in place.
And that's my take on the OP. Lots of "managers bad" without recognising the faults of engineers in that process.
I'm sorry to hear that, indeed, the engineers have to follow through on their end as well. That means "working" software, minimally functional, has to be delivered ASAP, at least to be able to gouge customer engagement.
"Design Patterns" and the latest "Web Framework" fad are the opposite of delivering working software. How you find people with the right mentality? I'm not sure.
Low-level game devs tend to have that "make it work" mentality but they like to reinvent the wheel a little too much because the existing wheel is 0.1% slower than their custom made one.
Web devs are the opposite, they seem to think the wheel has manifested itself from the ether. They probably don't even know about half of the 50 wheels they brought into the project, and they'll replace them with newer, shinier wheels in a week.
I think hiring a good team lead with the right priorities is key. Not a "manager", but the team member everyone else looks up to and follows out of their own volition. It might be worth wasting a lot of money and time on finding and hiring that person at the very beginning. If you do, the rest should fall into place, as they'll hire people who work well with them, meaning same priorities.
Look at the impact someone like Jim Keller had on the companies he worked for, as an example.
Yep, both managers and contributors have a faulty model of agile. We're all guilty of it, even those of us who know it when we see it because we know the theory so well.
Finding people with the right mentality is, as you say, very hard.
The temptation of the manager is to get people with the wrong mentality and wrap them enough process that it will fix them. The temptation of the contributor is to blame the manager without looking at their own faults.
As good a solution as I can suggest is to work with people who are willing to collaborate on a positive outcome, and go through genuine continuous improvement.
And just to clarify, I've been both the "shinny new framework" and the "I can make it 0.1% more efficient" guy at different points in my admittedly short career (still a senior though). These days I'm the "make it work" guy but only after suffering the negative outcomes of the other two a little too much. You only really "get it" after doing the "wrong" way first.
I've also had to deal with the "bad" manager that gives no push (nor any time) for stabilization, leading the code to a near-project-killing state of constant malfunction. Quite a few of the principles in the manifesto are about avoiding exactly this state, but they too are not followed correctly.
The following are in a different order in the manifesto, but I think this should be the way to read them, they almost form a coherent paragraph:
"Continuous attention to technical excellence and good design enhances agility. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely."
This means quality needs to be considered from the beginning and maintained, but that's not contradicting the fast delivery, quite the opposite (proven by many studies on Continuous Delivery).
Quality arises from constant refactoring the working code to be better, based on the results obtained from seeing that code running. Not from planning ahead with some insane micro-service bullshit architecture 3 months in advance for a project that probably will never scale to a size that needs that nonsense (at which point you deal with it).
But you have to give time for that cleanup work, and introduce a culture that demands that quality (where quality is measured by the software working well and delivering value, not by how theoretically "clean" the code is) otherwise it simply won't happen.
I've also had to deal with the "good" manager that tries to fix the above issues (after they happened) with processes. In my experience they just slow down velocity and don't resolve any of the actual problems. It's like telling a plumber that is almost swimming in shit to read and sign a 20 page document before turning off the valve of the pipe that's spewing brown liquid everywhere. That plumber is just going to hate you.
The only thing that works is to demand both continuous delivery and consistent quality (and allow time for the latter at the expense of the former if need be), ensure you have the right lead, communicate openly and regularly, and then let the team do its thing. If the devs and PMs don't see each other as allies rather than annoyances, the whole thing falls apart.
Also all it takes is 1 bad dev to spoil the bunch, I've seen them do so much damage it's nuts (stuff like introduce some whole new web framework nobody else in the team knows on some part of the project, or rework entire parts of the code to be async even though then it doesn't work with the rest of the codebase). Code review / pair programming is supposed to prevent this but if the team lead lacks the strength to keep devs like that in line, you're screwed anyway.
"Individuals and interactions over processes and tools"
If the individuals and interactions are wrong, no amount of processes and tools will fix it... I guess companies the size of Microsoft and Google can throw enough money at the problem that things work out somehow, despite the abysmal quality of most of their software.
I’m referring to the Medium Partner Program, which pays based on level of engagement with readers, particularly subscribers (as this is a Medium post).
It's not like the points he is bringing up are invalid though - and I say that as someone who actually likes using, creating and contributing to FOSS projects. Most of them eventually boil down to funding - it's rare that open source projects get decent funding or that big-co employees are allowed to feed back stuff back upstream. The result is a shit ton of people all doing what they want, but there is no overall vision where the ship should head - and those that do want to break the cycle of misery often enough get badly burned. Just look at systemd, how much hate it got and how it's practically unthinkable now for people to ship handcrafted initd scripts instead of a sane unit file?
How many Heartbleed, left-pad or whatever similar instances of catastrophe does the IT industry need to recognize that relying on self-exploitation and intermittent government grants is not the way forward?
Most discussions at large corporations are bikeshedding. Huge issues are ignored, but some minor detail which can be changed easily later gets talked about for weeks. It's often because its a detail middle management can understand, but the huge issue isn't.
You then have to spend a significant amount of time trying to guide people to focus on the right things. And that is draining.
The delivery of the message is a rant. It’s blunt and negative. But the content is something that many polite, loyal workers will tell you after a beer or two (so to speak).
You are mentioning perspective and priorities. But from what I know these are exactly the problem. The more people you have that are disconnected from production and use, the more BS work tends to get generated. Not only because of increased bureaucracy and overhead, but also because decisions get made by disjointed actors and are often based on buzzwords or company politics.
> You will be asked to write a 50-page documentation for some little code you wrote.
The author does not complain just about writing documentation, but about writing an unproportionate amount of it that presumably isn't being read by anyone. I've seen that happen. People writing essays about software that are bound to get outdated and will never be read by anyone. In systems that are disconnected from the source code.
> The writing is smug and shows no self awareness
Maybe I share the author's disdain for the corporate setting, but I don't see the smugness.
While the article may not acknowledge the cost and value of doing things slowly and bureaucratically, I fail to see how that is an expression of lack of self-awareness. It is mainly an expression of a preference for seeing direct change to business logic in a short amount of time, even for aging projects, because of direct ownership.
> The author does not complain just about writing documentation, but about writing an unproportionate amount of it that presumably isn't being read by anyone. I've seen that happen. People writing essays about software that are bound to get outdated and will never be read by anyone. In systems that are disconnected from the source code.
This has been the norm more often than not in most companies, especially larger ones. Hence the Agile Manifesto, written by people who've been there again and again.
And still, working in company that does not document what the system does, it sux massively more.
Because end result is that no one knows how to use our own software. You dont know what it is supposed to do, so it is impossible to keep that stuff working. It takes ridiculous amount of time to configure anything or reproduce bugs, because you need multiple calls to find the one person who barely remembers.
Also agile manifesto is 20 years old. Agile is literally what most large dysfunctional companies do these days. It does not have no new solutions to actual real problems of companies, because it is old.
The comment I replied to says "inappropriate amount of documentation", the Agile Manifesto says "comprehensive documentation".
That's the problem. Months, if not years, spent on pages after pages of comprehensive documentation that does not add any value and is obsolete by the time you start writing actual code.
Lastly, the age of something is not a relevant criterion. Not much has actually changed over the last 20 years. What has changed is the explosion of web-related software, which is actually the best suited for the ideas behind the Agile Manifesto.
> That's the problem. Months, if not years, spent on pages after pages of comprehensive documentation that does not add any value and is obsolete by the time you start writing actual code.
This picture is not any real company I ever worked in or real company I heard of from friends. Literally, not even before agile manifesto.
> Not much has actually changed over the last 20 years. What has changed is the explosion of web-related software, which is actually the best suited for ideas behind Agile.
That is not actually true, really. A lot did changed.
This also glosses over something else. Comprehensive documentation can even be really well documented code!
And in small corps, there's the "guy who wrote it" was "hit by a bus" scenario. It doesn't matter how dilligent, or how faithful someone may be when they leave, eg walking a replacement through the codebase can't happen of you're dead!
This is how I document. I think about being hit by a bus, and what would this corp do? A replacement hiree do? See?
Not doing this is, IMO, should be criminal. Like a CFO not keeping books.
People writing essays about software that are bound to get outdated and will never be read by anyone.
I write a lot of documentation entirely with the awareness that no one else will read it. I write it for myself. I don't want to have to remember the intricacies of a system. I want to write things down, then move on immediately, and have the security of something I can refer back to if I need it when I revisit the system.
But doing so is your personal preference, you (i hope) are not required to do so. Some people find it easier to organize their work differently or not at all. Some people are astonishingly productive despite not writing anything down, ever.
What if the teams changes? Intricacies must be documented despite that probably nobody will ever read it. Somebody might depend on it.
Writing code is more about communicating how to solve a problem than just solving a problem, that's how I view it. If you don't communicate, nobody except you will ever understand it. It might be that you don't need to document a lot, maybe most is obvious if the key parts are sufficiently explained. But it's vital and sometimes it's better to write a bit more than a bit less. A thing is, outdated documentation might be worse than none, so it's a delicate balance.
Yeah, documentation will definitely help in this case. With it, you can swap teams and even companies, and it still works! This only fails in companies which do not review documentation and have no routine for keeping it in sync and testing it on e.g. newcomers, like you do for backups. Cause otherwise it is as good as never tested six months old backup.
It's always fun if a product is based on 20 year old code where there are parts that nobody can touch because there's nobody around who understands what's going on there. I once saw a flight-training software (I think it was for helicopters?) where the physics engine just didn't get touched because they don't know what's going on. Every change was essentially a hack around this blob of years old, highly optimised but totally incomprehensible C.
EDIT: It might have even been fortran code. The rest of the project was C++
I once saw a flight-training software (I think it was for helicopters?) where the physics engine just didn't get touched because they don't know what's going on.
This is an interesting case, because it's something that I probably wouldn't document. Code should be readable. If you're writing down how your code works in a document then something is wrong with the code. Documentation can't fix an incomprehensible codebase. I document how algorithms work, what the business logic is for things (which is another algorithm really), how applications work in a 'data flow' sense, what integrations there are with external services and how they work, what things mean, and so on.
Normally working out how a complex piece of software works from only the source code is called reverse engineering.
I've encountered this "readable code means I don't have to document" idea before. I have no time for it, it's just wrong:
1. Important things aren't easily visible in the code, most commonly why the code does a particular thing. "Readable" code, which is a very subjective standard, can only tell you what it does but not the underlying rationale.
2. Writing docs often exposes the fact that the way the code works, or is expected to be used, doesn't make sense or is sub-optimal. If your docs include lots of caveats or explanations of nonsensical behaviour then it's a good hint you should go back and think again.
3. Figuring out stuff by reading the code is often drastically slower than reading the docs. That's why all professional APIs have good docs and people grumble and moan when expected to use code that doesn't.
4. The sort of people who argue this, in my experience, often don't actually write readable code, they just tell themselves they do.
This type of documentation is the only kind I have positive experience writing. Tutorial-like documentation is another kind I have positive experience reading.
I've never seen anyone having to write a 50-page document just for "some little code", unless the author's definition of "some little code" is drastically different from mine. Without anything to back it up, that statement comes across as a huge exaggeration.
Everyone is at a different stage in their lives. It feels like the author hasn't had much challenges and found most of the work boring. I agree with some of the points the author has raised but not all. I don't agree with your comment about "writing is smug and shows no self awareness". It feels like you're jumping to a conclusion.
Working directly for clients and being personally responsible for the entirety of the development process gives you this perspective. You can have successful multi-person projects with almost no documentation and project management contained entirely in a single trello board with basic features.
Then, when you land in a corporation you can see how large teams barely manage to match your former personal productivity by choosing wrong technologies, taking wrong approaches, discussing irrelevant things in countless meetings and producing tons of write-only never-read documentation that gets obsoleted almost as fast as it is written. If you are too youthful and idealistic you can get a little arrogant experiencing this inefficiencies when you have a context to fully appreciate their insanity.
Or you may take another approach. That efficiency actually doesn't matter. People don't work to achieve anything. They work to get paid. And corporations have a lot of money. So the game is no longer about building stuff efficiently. It's about raking in as much money as you can for as long as you can and every inefficiency that justifies further work is actually best friend of everybody involved.
“ So the game is no longer about building stuff efficiently. It's about raking in as much money as you can for as long as you can and every inefficiency that justifies further work is actually best friend of everybody involved.”
You’re describing the goals of the individual becoming divergent from the goals of the company.
In the article the writer described his team’s goals at the VFX software company as being well aligned with the goals of the company and the customers. They even stayed late because they were enjoying solving the problem so much.
The same misalignment in goals is what made Communist Russia so awful. The stated goals were about providing prosperity to all workers and citizens of the USSR, but the goals of the committees became about personal advancement and the preservation of the party. It could be argued that the extreme job security of the dictatorship allowed this situation. If there had been a way to democratically fire officials, they would have been more aligned with the goals of the people. (A politician is only as good as your ability to fire them.)
Many large companies end up like the USSR. The way to solve this is to allow teams to fire their managers.
"The way to solve this is to allow teams to fire their managers."
I don't follow. Wouldn't most teams replace their manager with a manager who would give everyone the biggest raises and the easiest working conditions?
Why would a team want a manager who cares about the goals of the company?
"That efficiency actually doesn't matter. People don't work to achieve anything. They work to get paid."
That is fine, but now you are stuck playing politics. You have to keep whoever is in charge of the money happy. And no value is created because everyone is trying to avoid getting blamed for problems.
Obviously, real companies, making real software also have to keep customers happy, but at least those requirements are somewhat predictable as they are tied to the real world use case, and real world value customers are getting from the product.
Author is every software engineer I hate to work with. One who thinks that code is the only truly important part of a project. It's not.
"Delivering a product that solves end user needs and is as maintainable and reliable as possible" is the only truly important thing, and only some of that is code.
Meetings generally aren't for developers. They're to keep everyone else involved with the project sync'd up.
Do I and every software engineer wish we had fewer meetings? Absolutely. Do I recognize that meetings are valuable to people not me and are critical in helping them deliver their (often non-code) parts of the project? Absolutely.
Not recognizing that after 20 years in the industry is baffling.
I'd be curious if author has ever worked on a large, 1 year+ project that went awry because the requirements were incomplete and the end users' needs poorly understood. If so, then I'm not sure they took the right introspective lessons away from that.
Edit: And I recognize that some companies are incapable of delivering software, due to broken development processes. I've worked for health insurance companies and know how baroque it can get. But that's been the exception rather than the rule.
I would even add that sometimes "maintainable and reliable" are overrated.
Sometimes being quick to market is more important then having to maintain the product. Sometimes providing a bad product is only relative to the competition (which may have a worse product). Sometimes having a good customer service is more important than the reliability of the product. etc.,.
I do agree with solving the end user needs... if a client does not need your product you really can't run a company for long.
In some fields having a good business and regulatory relationship with the customers (e.g., hospitals, DoD, banks, etc.,) is much tougher than building the product. There are many barriers in place and these fields are not so easily disrupted (having a superior product is definitely not enough).
Also note that having a bad product now that is better than the competition does not mean you cease to improve.
Exactly. I've worked in companies dominating a particular niche. Everything about the technology is "terrible" from an engineer's perspective, and yet nothing shifts their dominance. A massive rewrite that damages customer relationships is more risky than doing nothing to improve it.
It was Facebook's philosophy and also Twitter used to go down a lot in the early days. So I'm not sure I'd agree with your statement. It depends on your company culture.
In general, a well planned API allowed Facebook to integrate a lot of 3rd party features to attract more users. Simply put, a messy standard is still a standard.
Here is a quick CEO dilemma:
You have startup with about 4 people, you did a quick prototype, showed it to some potential customers and the worse has happened:
They want it! and they want it now!
The head engineer says it's all just a temp hack, it is completely shitty, they could give it to costumers but then the maintenance will be impossible, they will need months to add any new features on top of it, they will probably waste all their time on fixing bugs, and they'll quit if they have to maintain it for long.
What would you do? (A) continue develop until you have a nice maintainable product, or (B) sell the product now and face the consequence of wasted developer time and loss of their motivation.
Sometimes in such situations the answer is (A), but not always. It depends. How much money you got? how certain are you of the timeline for "finishing" the product properly? which option is riskier? How much competition you have and how likely they are to publish a product before you? What could having a real customer teach you about your product? What do you need in order to get the next round of investment?
This is just an example, but IMO product graveyard is filled with great maintainable and reliable code no one had a chance to use. I love software and I'm really not disregarding its importance, I just think it's not always the most important thing.
A CEO rarely accepts designing a product for a single customer. If you did, than your team just becomes dependent contractor labor rather than a business.
I will tell you a terrible secret of successful software companies:
"One doesn't make money writing software, but rather reselling the same software mullions of times over."
You seem to talk in absolutes while I'm just acknowledging there is more than one right answer.
And I do have specific real cases from my experience in mind... One of a great product that never finished (money ran out, CEO didn't want to provide something that was for "a single customer" as in your words), another of a shitty buggy unmaintainable software that did grow a company from 4 to 100 employees then to an exit and only then came the nice eased-back rewrite.
The 3 year survival odds are about 1:23 for software/services startups, and 1:70 for hardware projects.
I have culled many half-arsed options... and the decisions are far from arbitrary. Also, who budgets for a project burning over $100k a month in labor without a detailed plan... lol
Yes, I agree, there is a continuum there. It is easy to judge from afar, but it is much more insightful to see what people do in real situations with real resource constraints and complicated human beings trying to succeed -- and not always with the same definitions of success.
For example, for many engineers, what they (a) can learn and (b) be proud of while building a product is a big part of success.
For some CEOs, engineer satisfaction is only a secondary or tertiary goal -- their business success crowds out most other things. This is complex; sometimes this drive is what helps a business succeed; sometimes this is why people get treated poorly or ethics go out the window.
"what people do in real situations with real resource constraints"
As this is mostly on-topic for the parent thread... I can respond...
When faced with a painful product launch/schedule, as management messed up resource budgets etc... there are a few actions one can usually take:
1. ignore the issue, accept a 60% probability of failure risk, and naively hope management is replaced
2. adjust current project scope, follow MVP rules, and defer features for v2
3. cull the project, and eject unprofitable/unhelpful members from the team
4. Leave the company before the shite hits the fan
Note, compromising workmanship is not on the list, as a business "Brand" is often more important than non-stakeholder opinions of intangible asset valuation.
> Delivering a product that solves end user needs and is as maintainable and reliable as possible" is the only truly important thing, and only some of that is code.
that it should also bring money, or enough money, to be more precise.
It may sound strange but lots of products that fall on your very on-point definition fail to bring enough money in order to keep the lights on (and then some), this is a point that gets lost on many software developers. For context, I've been a paid programmer for 15+ years now, mostly in small companies, maybe as part of bigger companies/projects the view is a little different and "bringing in money" is not seen as that important for the developers.
> And this isn't to say that some companies aren't pathologically incapable of delivering software...
"isn't", "aren't", "incapable"
Three back-to-back negatives have me confused. Somewhat mysteriously, I (think I) understand what it means when I read it quickly, but if I pause to think I get confused. English isn't my first language :)
Negatives cancel, so I think you cancel the first 2 and get "this is to say that some companies are pathologically incapable of delivering software", which reads a bit nicer
Double-negatives in the "not+no" formulation tend to be a special case. The easiest rule (as you realized) would be "If there's a 'no' before the noun (direct object?), in an already negated phrase, then ignore the 'no'".
Undoubtedly, but it was a response to someone explaining how to use English (correctly), not how to understand someone else using English (possibly incorrectly).
If I say 'proper nouns have a capital first letter' I don't think 'actually oliver sometimes people don't do that' is helpful.
Was he hired as a product liaison with corporate to attend meetings with clients. No. He was likely hired as a developer. Most of this should appear as requirements via his inbox not be meetings he attends unless there is a screaming problem with a request.
Agreed on consultants. It provided so much enlightenment on the multitudinous ways many companies can screw up the discovery and development process.
Setting aside the "This company was fundamentally disfunctional" cases, my takeaway has been that knowledge gaps between roles are an underappreciated cause of bad development outcomes.
Writing requirements is hard. Writing requirements without some intuition of what developers need to know is harder. Writing requirements without context on the business domain is harder.
So the ideal BA is someone who is a developer who is also experienced in the business domain.
The majority of companies don't want to pay enough to hire BAs with that experience.
So you get users (who may know nothing about software) + minimum cost BA (who is doing their best, but has no context for anything) coming up with requirements, which are of course incomplete and/or incorrect.
But fundamentally this problem is too large of a skill/knowledge gap between the user and BA, and between the BA and the developer.
A few days ago, I made a comment about good developers knowing how to think of their work from the business’s perspective. One guy responded by saying his only job is to write code and he doesn’t care about anything else. I just can’t imagine coming to that perspective, even if I understand the desire to have minimal responsibility.
> One guy responded by saying his only job is to write code and he doesn’t care about anything else.
Which is such a weird perspective to me. The point of writing software for business is to solve a business problem. Maybe it's a function of working in small companies and/or roles that straddle code writing and business, but I have a hard time writing good code unless I know the business problem space.
It's also why I think I don't get too worked up in the language arguments. I've written code from VB5 to Java to Go to JS all which deliver immense business value. When I think about the best code I've ever written, I don't think about how pretty it was or even the language, but is it still in use 5-10-20 years later.
Code 'longevity' is influenced by many more factors than code quality; e.g. rate of business change, traffic changes, infrastructure dependencies, and the complexity of the surrounding system.
As a pathological counter example think about arcane obtuse code that people are afraid to modify.
That's a good point. I didn't really define what I meant by 'best'. In some cases the code was used, updated, etc... for many many years by people I knew. If people were too afraid to touch it when a bug was found, then definitely not good. But, if people had no need to touch it b/c it works, that's a good spot to be also.
I think it's a failure to separate work and hobby. A lot of — heck, maybe even most — developers get into it because they enjoy programming. That's entirely reasonable, but you have to accept that some compromise is going to be required of you in the working world. You can't just do whatever you want to because it's fun and get paid for it.
If you find yourself empathising with the author, you really only have two choices:
a) Quit, do something else for a living, enjoy your programming in your spare time
b) Suck it up
Even rock stars have to sit in meetings and do things they'd rather not, like hold press conferences, give interviews, etc.
At many big companies there is plenty of room for those types of people. They just need to be put in a role where their customer is another developer. They can see things from the developer perspective and can be plenty successful working on things that are not public facing.
As a developer (and sysadmin), I want to write less and less code as time passes. It's not I don't enjoy coding, on the contrary.
However, I understand that a project is documentation and future planning, too. So, I want to build an artifact complete with its documentation, which can be sustainably moved forward by anyone other than me.
If I don't document what I've coded, then the joy project becomes a weight on me, and prevents me from moving to new, bigger things. Also, I can show the whole shebang as "I made dis!", and anybody can have an idea what the project is all about.
As a developer, I've been writing lots and lots of code every day for around 15 years. I write documentation quite rarely, only when it's a customer facing feature (a lot of stuff that I do is in the background where customers have no idea things are happening) or a very technical piece of code that I want future developers to understand better and keep the intended design in mind when making changes (this is much more common for me to do). Most documentation, however, can easily get stale almost as soon as it's been written, so with experience, you learn to focus on the important concepts as opposed to implementation details..
I rarely have meetings about things are not entirely technical, and I actually enjoy the meetings we have as we always come up with valid points that one alone may not have considered.
Anyway, just wanted to mention my experience as I don't agree that as you become more experienced, you tend to write less code. I am as productive now as I've ever been, even being one of the main and most experienced developers in a team of 20+.
Ah, no, I didn't mean to share my perspective as "this is the correct way, yo shall do as me". It's just my perspective and formed by my own experience and work structure.
As it comes up here from time to time, I work as a sysadmin, and have my side academic gig, which I'm the solo developer on a serious piece of code. I design, code, test and verify the whole thing, which is immensely satisfying.
My daily job is very connected to my academic gig, and they feed each other. As a result, I can apply what I've learnt from one to the other. We're a small team, doing a lot of big things, hence my work environment is drastically different than yours.
The gist of my comment was actually, "As I get more experienced, I design and write less code because it's more correct from get go. Then I document it at the level needed and I have something concrete and which can be passed over to anyone who wants to maintain or fork it, and this is equally, if not more satisfying".
The thing is, there is absolutely a cost for all those meetings. Time spent working with stakeholders and building consensus takes away from the urgency and energy you can devote to good work.
My experience is very similar to the article's. I just draw a very different set of conclusions.
For risk averse, cost constrained, low stakes projects.
Good engineering work is neither demanded or required..
My viewpoint is simple.
Don't work on software nobody cares about.
Work on software that's doing something genuinely important.
Then people will feel obliged to cut the meetings short and be more efficient.
> Meetings generally aren't for developers. They're to keep everyone else involved with the project sync'd up.
But if every project has non-developers deeply involved in them then the software is very shallow. So to me anyone who thinks that every developer needs to be involved in such meetings just shows they have never worked on anything deeper than a crud app with some basic business logic. If you work on anything like a compiler, a garbage collector, a database engine, a load balancer, any kind of software framework etc then you will have plenty of teams never needing to talk to non-developers.
> If you work on anything like a compiler, a garbage collector, a database engine, a load balancer, any kind of software framework etc then you will have plenty of teams never needing to talk to non-developers.
Replace non-developers with "people outside your immediate team". In a developers-all-the-way-down shop, there are still people who are intricately dependant-on but not involved-in your work.
But developers are much better at describing what they need so there is much less need for meetings in those scenarios, instead they just send emails or open bug reports that gets resolved without the meetings.
Generally, I'd agree, but I've also worked with developers who are as egotistical, shortsighted, and/or stupid as the worst person with any other title.
Being a logical, cooperative, well-communicating human being is not a requirement to be a developer.
> Being a logical, cooperative, well-communicating human being is not a requirement to be a developer.
If your company is fine with them being unable to communicate then your company obviously is fine with you not being able to communicate as well, so why try? And if your company hires people who are good at communicating then there is little need for meetings between developers except politics, and most developers shouldn't have to deal directly with company politics.
How we write here on HN is important. Write once with overgeneralizations, and then N >> 1 (many more than one person) have to read that sloppy thinking. It is lazy writing/thinking and, in effect, disrespects our collective experience.
To be honest, pretty much all the experienced developers I met understood that. The "my silo and nothing else" kind of thinking tends to be something unexperienced people are more prone to.
Yes -and- it isn't just political speech. Many developers naturally feel more comfortable with certain information sources (forums, blog posts, people, etc) and form self-reinforcing tribes around e.g. programming styles, languages, habits, editors, processes, and so on.
I mean the author mentions meetings about the color of a chart... it's the kind of meeting they should be able to reject, because I don't believe they would have much of an opinion on the matter, only a decision that they can implement.
So if you're in a position like that, assert yourself and your presence in meetings; do you have valuable input that they need? Is there a time set, a concrete goal / agenda? If you don't have to be there for any other reason but to be kept in the loop, can they just send a tl;dr?
I mean I get that a lot of things need to be discussed - and a subject like chart colors can be reused for years after the decision was made - but not everything should be an all hands meeting. Have the least amount of people in a meeting to come to a decision and keep others in the loop. Let everyone do what they do best.
I would argue most meetings can be mostly replaced with ticket comments, documentation, emails, and chats. Devs are constantly expected to adapt and learn new things, while others apparently don't need to learn to use comments, documentation, emails, and chats to stay informed.
Learning to use search features should be a good step as well. Outlook has search, Azure DevOps has search, there's Google, and most chat programs have search as well. Some developers need to learn to use these too.
You don't have to be a wizard at search engine flags or features or anything - it just needs to be the first thing you do to avoid shallow, easy-to-answer questions.
> I would argue most meetings can be mostly replaced with ticket comments, documentation, emails, and chats.
s/would/should/
The real benefit of those forms of communication is that you have a written, hopefully searchable, record of the discussion. It also forces people to mold their incoherent thoughts into complete sentences.
Meetings should be reserved for brainstorming and decision making.
Many meetings can indeed be emails. Developers tend to be only so-so at identifying which meetings these actually are. And developers are terrible at identifying which two week long email threads could have been a short meeting.
It isn't enough to say "there are too many meetings" and be done with it. You need to identify which meetings can be removed - and that can be tricky.
Yes! My reply to "this meeting could have been an E-mail" is often: "OK, do you read your E-mail and respond promptly?" I love killing productivity-draining meetings and turning them asynchronous --BUT-- these meetings often get called because a decision needs to be made synchronously(now), and the decision makers can't wait two weeks while you get around to reading your E-mail and remembering to answer.
Those meetings that are simply "status story time" where someone reads a doc to the room? Yea, they should be removed. I don't think anyone likes them.
Yeah but you get tired of the fact that all of the low level business people abuse their "rank" to turn you into their personal assistant.
If I have to help them with everything, why don't I just talk to the users directly and write the requirements myself? It would be faster, and can even save the paperwork. This is modus operandi for contractors.
Why do I have to drag along these type of bozos all the time, and suck up to them like they are my masters. Cut the fat and get rid of the useless bureaucrats. Or at least get rid of this stupid "rank" that programmers are "the bottom of the food chain" so they can at least root out the shitty PMs.
Nobody complained when Steve Jobs delivered much more sharp-tongued rants than this article.
> but complaining about needing to do documentation, or basic project management
There's a difference between "writing documentation that fits the need at the moment" or "write fifty thousand pages of documentation no one will ever read, just to check a checkbox on some manager's checklist / compliance requirement". Or endless "sync" meetings that are effectively nothing more than filling the desire of managers to (micro-)manage.
With a decade of industry experience from freelancing over small agencies to big-corp/government jobs I've worked, I can say this: The core problem at the root of most big-co/government projects and associated disasters is that there are way too many levels of "deciders" and especially a fundamental lack of trust in people to do the right thing. When everyone is just in cover-your-ass mode and no one is willing to risk making a decision that is not backed by weeks worth of analytics and big data, shit will hit the fan real hard sooner or later.
The most successful projects are done by startups or in the big-co world where a significantly high-up person says "we're going to deliver a solution to the problem X" and everyone is focused on reaching that holistic (!) milestone, not on micro-optimizing their KPIs, OKRs or other bullshit. The key to success is trust, the focus on one shared goal and actually paying enough to hire decent seniors to lead.
> complaining about needing to do documentation, or basic project management?
Some engineers are allergic to teamwork. I deal with coworkers with a similar attitude on a daily basis.
The most frustrating aspect of it is that companies are usually bad at acknowledging someone is a bad fit for a project or a team, even when they are shown solid evidence.
A big part of it has to do with how broken the interviewing process is - the focus at the moment is almost entirely on coding exercises and ignore tasks that many developers perceive as boring but can be crucial, such as writing documentation. It leads to mixed results where you end up hiring some engineers with T-shaped skills along with absolute code monkeys.
Focusing on the author instead of the discussing the topic really misses the point imho. We don't get good discussions from it. The point is the amount of inefficiences in big corps and how people react to it. This post has so many upvotes for a reason.
Unfortunately what you have just said is given as a shining example of why some coders hate other coders. If they're not going to contribute to core work, then add "perceived value" like docuemntation which a good manager should be allocating people to rather than wasting time in more meetings.
There is no real excuse why when you're paid to code you're not doing that 4-5hours a day at least 5 days a week. Career development is one thing, but there are 7 working hours between 9-5 so if someone wanted to work on that they have a full 10-15hrs a week excluding a break for lunch.
Lets take out 5hrs of meetings a week which is still likely too much to be productive and we're down to: ~10hr for personal growth, ~5hr for lunches, ~5hr of meetings to keep people up to date and 20hr of actual work every week out of every employee.
Some meetings are important. Most are not. This is another common problem that middle-management gets into. Constant cracking of the whip and arguing-about/discussing small details is just toxic to productivity.
(Small here being what style/color/toolkit. Not knocking up a prototype and pivoting when needed based on strategy and risk analysis performed at the start of a good project).
Most "divergences" or decisions can be worked out through a SWAT analysis (yes I'm quoting Scilicon valley), or by managers making decisions and pissing someone off some of the time rather than holding everyone back all of the time.
I've worked for managers with both management styles and I can guarantee the boss that makes a decision (even if it's wrong) is better than the boss that holds 5 meetings on the topic, because often you'll either get over it and move on, or prove it's wrong by the 2nd/3rd meeting and will still be ahead of the 5-meeting nod-fest.
This mantra of hire more bad coders or letting talented coders go to waste because they're not being allowed to do their jobs is adding to a huge bubble in the sector and frankly, on the precipice of a major recession I think people in such companies should be starting to panic.
I think if you read the author's other posts, they appear to just enjoy ranting. I wouldn't be surprised if they manifested after a beer or two considering how myopic and exaggerated they become.
Alongside this we also have: open source is inferior because of... reasons, something about older developers ageing like fine wine unless they work as web developers with all of those young whippersnappers learning new JS frameworks every month, something else about maths and algorithms but is really about Big O Notation being bullshit.
Not to dismiss the author's point: I'd like to believe they're being genuine and not just being controversial for clicks. But they have quite the chip on their shoulder it seems.
Also, it is quite amusing. I do enjoy the occasional rant.
Can you point out where he is wrong, though? His criticism might not be true for all teams in all large companies, bIt I've worked at one of the FAANG companies and left for the same reasons. And I know similar stories from friends and ex-colleagues.
> but complaining about needing to do documentation
Here is what the blog post writes:
> You will be asked to write a 50-page documentation for some little code you wrote.
The parent post (^) misread and mischaracterized the blog post. It is notable that the ^ called the other author 'smug' and then proceeded to respond to the least charitable interpretation.
I agree that the tone of the article is off but I don't agree with this statement:
> Obviously there are inefficiencies with big companies, but complaining about needing to do documentation, or basic project management?
This sounds like you've never been in a big org where you write more word docs than you do code. I have. It was terrible for a few reasons:
* Those docs go out of date with the code very quickly and so are not a good reference to what the code actually does
* They eat up a lot of project time and so projects tend to become late. As the documentation is what you have to write first by the time you get to the code you have much less time to actually write the dam code
* Extreme documentation actually reduces code quality. I've worked on many code bases where the code actually references page numbers and sections rather than what it actually doing. This is often the case with contractors that are only on project for a short amount of time and thus translate the docs directly into code. Also if there are and errors when creating these docs they are often translated into the code often into performance / non-functional problems
* Docs written after the fact end up being rather pointless / unusable as you'll have to describe all the weird things you done to make it work properly / fast ...etc
* Non technical people will read what you've written not understand it, because it's highly technical, misinterpret it then use that strange idea of things they've got all over the place. Like someone that doesn't know what a Foreign Key is but seen it once and sticks them on every column in the DB. Then you'll have to have a fight with them as "it says here on this doc"
I could go on but I suspect what I've written here is quite unpopular so I'll end by saying that documentation is very hard to write correctly you need specialists who know exactly how to describe what's been done in the system to others. You also need to balance the amount of docs you create vs the actual work on creating the thing.
Again on Project Management you described it as "Obviously there are inefficiencies with big companies" that sounds like you've never been in a full 8 hour days worth of meetings getting 0 coding done and just explaining to 10 different managers what needs to be done. Some of these big corporates are so colossally inefficient that people have been quitting on mass during the pandemic to get away from it. It's a serious problem not just to be swept under the rug like oh well that's just what big companies do. I heard someone either on reddit or on here defend a 3 hour long "daily standup" meeting because it was good to know what the devs are doing. Like yeah there are in you meeting for 1/2 of the day.
Now I don't condone 0 project management but companies seriously need to cut it back. Tools like Jira have made working hell for some programmers.
> but complaining about needing to do documentation, or basic project management?
I think you missed the point about documentation and project management taking inordinate amount of time and manpower compared to the output in both quantity and quality.
That's fair, and given the tone I wouldn't be surprised if there were some very exaggerated #s there. But if accurate 1-2 hours a day of coding on average is pretty bad. Meeting etc are necessary but it shouldn't be that bad.
The more years I have spent in my career, I have come to realise that coding and implementation of something is NOT the only productive part of the project. Even though I like to roll up my sleeves and "just get it done already", I have matured to understand that (1) scoping a problem correctly and aligning it to a function of the product, (2) documenting the need and its integration with other parts of the project/company are much harder and more important actions that makes sure that you're implementing the right thing and not wasting/overengineering the feature.
It takes a bit more perspective to understand that no one can know it all or do it all. Contributors other than "coders" and implementors such as Product owner, scrum master, tester, manager play a key role in guiding the implementation. By the nature of those jobs, they are not as quantitatively measurable as an engineer's job.
I think this is a little of column A and a little of column B. Just as there are good and bad developers, there are people who are good and bad at running projects and organizations. The author feels that something is wrong. He knows he is not working anywhere near his full capacity and that the organization created this environment. He also highlights a lack of growth opportunities at some companies. What he doesn't do is highlight solutions or recognize why certain behaviors are key in certain environments.
Toward that end, I would recommend three old and poorly written books with timeless and wonderful ideas: The Goal, Critical Chain, and Managing Corporate Lifecycles.
While these books are all about management and running a company, I think they lend perspective to developers on why certain things happen the way they do. They can also help someone recognize and pick a healthy organization to work in. Just like books on software development, these books augment experience, they don't replace the need for it.
I tend to think most of engineering is rather mundane but potentially very rewarding. I hate meetings and overly complicated project coordination just as much the next person but there is also danger in wanting to do ‘cool stuff’ - imagine a dentist who is passionate about pulling teeth out.
A project that I quite enjoyed involved months of investigation work, finally solved by tweaking a single software parameter that dictated how far a release mechanism moved. The number of internal/external meetings I had to demonstrate that this can indeed fix the problem could have seemed silly but it was also very reasonable given the risks involved.
> I hate meetings and overly complicated project coordination just as much the next person but there is also danger in wanting to do ‘cool stuff’ - imagine a dentist who is passionate about pulling teeth out.
There was a case here were an (employed) dentist was apparently bored and started to drill and fill perfectly healthy teeth. Iirc, criminal charges were filed.
Malpractice because bored (or feeling undervalued/underappreciated etc.) isn't just a problem for SWEs, but actual doctors. Also see: nurses and doctors inducing code blues to get to be the hero saving the patient; firemen becoming arsonists to have a fire to extinguish.
Not sure how many good studies there are on it, but the likelihood of an unnecessary operation occurring are strongly linked to that months financials.
> imagine a dentist who is passionate about pulling teeth out
That's a great metaphor for code-before-you-know developers.
> finally solved by tweaking a single software parameter that dictated how far a release mechanism moved
I think of this type of work as programming by other means. The problem couldn't have been "fixed" without all the discovery meetings and understanding. The "fix" couldn't have made it to production without political agreement.
Is that computer code? No. Is it building a solution to interact with a complex system (of people), using the primitives available to you (less than VP-style "Just do it"), to realize a desired outcome? Yes.
Others may be different, but I find hacking obtuse process problems and corporate political structures just as fun and rewarding as a nice piece of code.
> Imagine a dentist who is passionate about pulling teeth out ... That's a great metaphor for code-before-you-know developers.
A key difference between a big decision and a small decision is what it's like to change your decision afterwards.
I don't think we can compare reverting a pulled tooth vs 2 hours of programming the "wrong" thing.
In the programming case, you may have went down a rabbit hole that wasn't correct but at least now you're 1 step closer to the right solution. You probably learned something and the business can write that off as R&D.
In the pulled tooth case, well, I'm not sure I want to Google that haha. Is it possible to fully replant a pulled tooth in a way where it's 100% healthy and you'd never notice it was pulled? I know there's implants but I mean the real natural tooth, complete with its root. I'm sure the process in any case would not be fun for the person who needs the work done.
You could classify one of these as a small decision and the other one as large.
I still think planning and understanding the problem before coding most things is a very good idea btw, but I would feel way more comfortable experimenting with code in short periods of time vs experimenting in a dental chair / operating room.
I maybe wrong but let me paraphrase what I think they meant (and why I think it's a great analogy).
I don't want my teeth pulled just because. If it's a fix to a problem - a means to an end - and there's no other way to do it, I'll consider it. Likewise, I don't want to work with developers who are super passionate about typing code into vim. I want to work with developers who are passionate about solving problems. Code can be a means to that end, and by the time it gets to us we typically already know we need some code for it, but the danger is spending days or weeks writing code nobody needs and nobody asked for because it's "their passion."
Also, I see every custom line of code written as a future burden. Part of software engineering is effectively minimizing and managing that burden.
If we write 10,000 LoC for something that we didn't end up needing... the team's going to be tempted to wrangle that into the actual purpose instead of throwing it out.
So overly aggressive fingers on keyboard lead to more bloated results, as requirements drift during development and more code is written to target them.
Meetings advance problem-solving insofar as they inform the code eventually typed into vim.
Some problems genuinely require a lot of this kind of deliberation, but most don’t. Some meetings aimed at this kind of deliberation make meaningful progress, but most don’t. The person who can terminate or pre-empt an inflated or stalled conversation with working code is extremely valuable.
Even if that code is not the ultimate solution, it has a definite shape and objective properties that can be investigated and weighed, which brings rigor to discussions that get lost in abstraction.
Organizational politics and entropy also tend to create too much talking: it is good for your career to present the work you’re doing as requiring a lot of collaboration (whether or not it does), it is easier to spitball in meetings than to actually solve problems (if you even have the skills), and you have to go to all the meetings you’re invited to (while coding time gets ruthlessly prioritized).
> imagine a dentist who is passionate about pulling teeth out
Exactly. Many times, the best code is no code. And making decisions about what code to write need meetings, unfortunately, or at the very least some kind of coordination.
There is really some questions that should be asked: Why are we doing this? For what reason it has to be done this way? Do we need to do this at all? What do you actually want? And so on.
Meetings are useful to clear up this stuff and at best result there is simpler solution, or not need to do work at all.
However it is often the case that programmers "at the leaves of org charts" (to paraphrase another commenter) won't get to participate on meetings that can define if something can be replaced by "less code", let alone "no code".
In small orgs with a headcount of tens that's very easy for developers to grasp the value and the need for certain things.
But when you're in a 1000+ developer organization it is often the case that the reason you have to do something is because this is a requirement coming from two or three management levels above.
In some orgs, a lowly developer might even be unable to even sit at the table with the big boys. They might have a say and a good perspective in micro decisions, but not in macro ones. In this case, I can definitely see TFA being written.
To use the dentist example, imagine a dentist that's passionate about pulling teeth, but doesn't get a say on wether the teeth should be pulled or not.
> You will be asked to write a documentation for some little code you wrote. You will carry out tests. You will argue with your colleagues and supervisor on every decision you make.
You misquoted in order to leave out the fact that the documentation is 50 pages, and some of the tests are useless, and arguing with colleagues is not always productive.
I removed the obvious exxagerations. of course nobody ask you 50 pages, so why is it relevant for the discussion? and who decides for how much documentation is needed anyway? the producer, or who pays for it?
also, you don't know which tests are and arent useless beforehand. code coverage may not be the perfect metric, but correctness is is semi-decidable anyway, so if one claims before hand that some coverage test is useless, he's most likely being lazy or drown in his self importance.
and arguing technical decision is always productive, so much that rubbe ducking is an actual methodology becuse even arguing alone is better than go head down with aggressive randomness.
Sorry but you are wrong. Useless documentation, useless tests and useless arguing definitely exist, period, and they are tautologically bad. Maybe you haven't had the experience of working in such an environment where those things happen, but claiming they don't exist and twisting someone's words is absurd. Also, those wild uncharitable and provocative interpretations are also against the HN guidelines.
I'm claiming they're not universally bad, and that the claim they're universally bad is absurd - if unsure about the interpretation, please do refer to the initial post - you might want to start applying that charitable interpretation thing.
The author himself didn't claim they're universally bad, nor did anyone else. The only "claim" for that is in your original post, where you misquoted the author on purpose! You can't completely twist someone else's words and then use that as an argument. And I don't see how referring to a post where you're twisting someone's words has anything to do with charitable interpretations.
If you think obvious exaggeration are foundational to the argument instead of a figure of speech nothing further is to be gained here.
Besides I've provided reasoning for the elision and that went completely unaddressed, probably because assigning some absolutism to the argument that wasn't there and dragging me to court on trumped charges seemed easier
The problem is that the removal of what you call "obvious exaggeration" and "figure of speech" completely changes the meaning of the phrase and transforms the author's position from reasonable to unreasonable.
That's called a strawman. Yeah, it's very easy to do and very convenient to knock out, and I hope you had fun doing so, but you didn't really address the author's real position here, as much as you insist that you just removed "figure of speech".
About the "dragging me to court on trumped charges" part, oh, the irony. That's exactly what YOU are doing. :)
I’m always up for a productive discussion, but there are two paragraphs of text before the one you’re childishly replying to, which you dishonestly chose to ignore in order to make a childish personal attack. Just like you chose to ignore the qualifiers written in the article in your original post. Sorry, but you don't get to cry foul and say you're being "dragged to court" when you're caught misquoting and then misrepresenting someone's position with a strawman. Either be honest or accept someone calling you out.
If you're really asking for an arguments: the fact you had to edit the quote should be enough clue that the original statement wasn't as clear cut as you're portraying. The fact people disagreed with you (with downvotes or comments) should also point to that. Maybe take a second to consider that you were uncharitable to the author and they're not as stupid and as extremist as you're painting them.
Once again you chose to selectively ignore most of the message and edit it to focus on a part you can use to paint me in the worse possible light. Similar to how you did with your original post. Your only tactic in this discussion is to selectively quote people to make them look worse. You are indeed acting like a child in this discussion.
And, no: that’s not a personal attack, as I’m talking about your acts, not yourself.
Once again I’m up for any discussion, but that won’t matter as you ignore anything that can’t be used to make your interlocutor look stupid. You sir haven’t argued in good faith. You began this whole thing with a bad faith misquote, and when you couldn’t do it anymore you began to cry foul, while at the same time criticizing me for doing so. And that’s the only thing you’ve done so far: acting in bad faith.
really? beacuse it appears from the last six or so messages you're only interested in dissecting words, ignoring whatever meaning is therein contained, and you're only available to debate the single topic that you picked, which today appears to be wether making summaries is allowed or not while presenting an argument, and are prepared to just diss and dismiss anything unless it falls exactly in your extremely narrow debate window.
I worked in the past at a company where Softbank asked for the dev headcount to be increased as a condition of the funding. Lots of teams ended up being responsible for halves of pages, half of a microservice, etc.
I think that many "software companies" are actually marketing companies that plan to make almost all of their profit from a product that has already been built. They're not necessarily a joke... it's just that software engineering is no longer their main business.
I think I had more or less the same conversation with a coworker recently, I also have 15+ years experience in building software and I think that software is useless and the point to build a project by itself in 5 months is naive, software developers have a value if the thing they’re building serve a purpose, and the purpose needs to be defined through meeting people with the domain
To me this post has junior dev perspective but also the coworker I had the conversation with is in his 40s and I’m starting to think there is some generational thing going on here
> Believe me when I tell you that I could have worked on the entire software myself in 5 months
Sure. People always over-estimate their abilities, and under-estimate problem complexity. It's easy to say something like the above when you're already looking at the solution.
Finding out what needs doing - through meetings, documentation and so on - is very much a part of software development unless there is only one developer and he is also the only stake holder.
This isn't even necessarily inefficient, because productively doing work that isn't needed isn't helping anyone either.
We had this "important project" coming up, a certain big feature that was wanted in the platform. A project which would take about 6-9 months with the collaboration of various teams across the company.
I was involved but only in a helping role. One member of my team was involved but they were fairly inexperienced and so I was asked to go in as support.
After the first two meetings a number of things became clear. Mainly that the product owner for the project was extremely ambitious, clearly not knowledgeable about the technology involved and got very upset about any concerns or problems anyone would point out. They wanted "those stupid meetings" to be just for informing them of solutions and progress, not for discussing problems and options.
At the third meeting I made the mistake of mentioning that a particular detail, not too important, would be extremely costly to do as asked and that we would be better off doing it in a much simpler form. Unbeknown to me, that day the product owner went behind my back and asked for me to be immediately removed from the project. So I was. I didn't care much for it and I only learnt about that move much later, when I had already left the company.
Anyway, the project ended up taking about 2 to 2 and 1/2 years and it had to really reduce its scope in the end. And some of the people involved confessed that it was because of the product owner, because they had wanted people to "just build this thing I say and stop arguing". A lot of work was simply thrown away several times simply because of not having had the proper discussions it needed.
Imagine actually caring, my aim is to get away with as little work as I can while still earning good money. ‘No nonsense coding and learning’ cringe, imagine actually liking to write software. After 11 years of embedded dev, I can safely say I rather not write a single line of code ever again. This whole industry is 99% bullshit. Thankfully I could exploit it for a lot of monetary gains
I agree. Actually, I have never met anyone who has liked writing code. How much code do any of these high profile programmers even write anymore? Linus, etc? If the leaders of the industry don't even write code, it says a lot.
I've been writing code for 16 years, which is now over half of my life.
I've been a full time software engineer (now lead) for the last 9 years. I've been in similar situations to this article where most of my time was spent in useless meetings that I disliked, I tried to improve things, to focus meetings, to improve our efficiency.
And all that aside I still love coding. Granted not all types of code, not the one I have to write sometimes at work.
Just now I'm starting another little fun side project that I've been coding on my free time these last few weeks.
All this is to say that coding is just a little tool, what you build with the tool is what can be fun. I think it can be healthy to write code that does fun things from time to time, even if the code you write at work is for the most boring aim.
I'm glad someone else said it. I want to think of problems that other people write the code to solve for me. I'm so tired of having an idea and no one but myself to work on it. It's led to a nice GitHub portfolio but I'd have rather that the stuff I built had existed already.
This is mainly because most other people can execute with a better level of completeness than I can in the context of open source dev. This is mainly because I don't actually like programming, but I sure as shit love the niche I am programming for...
I love writing code, nice to meet you. I know lots of people who love writing code. (Side note I also do see the value in meetings too.) I work with some relatively high profile programmers in my field (computer graphics) who still write lots of code, and will continue to do so until they retire.
Linus doesn’t write any code, in his own words, but that’s in part because his knowledge of software makes him better at leading people than writing code now. But Linus is not all leaders of the industry, many of them still do write code. John Carmack still writes code. That said, why should high profile programmers continue to code? What exactly does it say if they move into management?
I assumed you were being sarcastic, but re-reading your post and looking at the replies, I guess you're being serious here - I do actually like writing software. I'm not pretending or fooling myself - besides playing music and raising vegetables it's one of the few SFW activities I actually enjoy. I tolerate meetings because they're part of the price to get to write software and actually get paid to do it. What I don't enjoy are the unreasonable expectations around how long things ought to take or how predictable software development ought to be.
Every company I have worked at has been the same - very depressed people who have no enthusiasm for anything slowly dying as they sit there staring at the computer. It is in stark contrast to the physical labour jobs I have had, which have been very lively and happy places to work.
I think the assumption that these people want to program for more than 2 hours per day is probably wrong, and you will just burn yourself out trying to do 8 hours of programming every day. In fact, many of these people burnt out long ago and just try to find anything other than programming to do.
I wonder though, it is true that these companies are very inefficient, yet they never get taken over or superseded. Why can't the group of rogue programmers that are more productive take over any of these companies?
Interesting observation. I wonder how much of the difference is between high physical activity, where often the work requires multiple people manipulating the same physical object (I hold the door, you attach the hinge),
vs
low physical activity, where often the work requires multiple people manipulating highly abstract concepts with purely imaginary connections (I write the API, you write the caller).
The physical/non-physical distinction might be a bit of a red herring, as this seems more a differentiation between repetitive and non-repetitive work.
I.e. assembly line worker vs carpenter
I'd hazard most people tend to dislike repetitive work, if they have the choice.
As someone who has dug ditches in Georgia clay, agreed.
Although I guess even the most repetitive physical task still has infinite physical fidelity, if you look for it. E.g. digging a hole in the same place 50 times vs writing the same code 50 times.
It's the middle ground that is mind-destroying. Extremely repetitive work lets you turn your brain off or redirect it to more worthwhile thoughts. Non-repetitive work keeps your brain engaged with the task at hand. The middle ground requires too much engagement to focus on other things but also leaves too many gaps to remain focused on the nominal task.
Our minds generally don't work well on repetitive tasks requiring high concentration with low interactivity. Yet, we're so irrational we can't see the obvious.
Take a "self driving car". Except... you can't really crawl into the back seat and eat lunch. No. Are you kidding me? You have to pay attention! You have to be ready to grab the wheel! A walrus could be napping on the freeway! Just because it's self driving doesn't mean you don't have to pay attention! Good god, what's wrong with you?
What's wrong with us, collectively, is we don't immediately recognize the absurdity of what they're saying. There's really something very very wrong with that person.
> Every company I have worked at has been the same - very depressed people who have no enthusiasm for anything slowly dying as they sit there staring at the computer. It is in stark contrast to the physical labour jobs I have had, which have been very lively and happy places to work.
They even made a movie with that premise (Office Space).
I work in bursts. I probably code 1/3 of the work week. The rest is spent on meetings, helping others, looking at logs/data and keeping up to date on tech. I think that is a healthy balance. There are many ways of adding value to a business.
1. For whatever external or internal reason, they fail at writing good software for a long time
2. The job takes a terrible physical toll (lack of exercise)
Neither of these are improved by larping at corporate business stuff around the office.
Maybe line cooks at slow restaurants have fun getting high and chatting while they cook, but many many jobs are physically painful, intensive and low-rest, and/or high stress and bad hours service work.
I feel like line cook is the worst example of a fun physical job. Most of the line cooks I know are incredibly burnt out and survive their 12 hour shifts by abusing cocaine and amphetamines. Landscape contracting seems much tamer by comparison.
Software engineering is a group effort with lots of components other than coding.
It is very very seldom a lone operation and all those are tiny products with tiny scope (if results in a viable product at all!).
Deciding upon the features, figuring out what is the best to do in a plethora of criteria involving finance, technology, organization takes much longer than the actual coding and involves the communication (spoken, written, presented, etc.), no suprise there.
Management could many times done better of course, managers are as lazy or incompetent as other people, if not more.
I've worked at all company sizes from big tech, scale ups, and early stage startups. From my experience, I've learnt the most and done a lot of interesting work when the company size was smaller. Although a lot of people seem to care most about what I did at the big tech company and get surprised when I tell them I spent the whole sprint fixing some line on some sub menu.
I was expecting to find some interesting thoughts on this one, but its the usual rant of the "freelancer" who does not understand what production means!
Yes big companies have productivity issues, however they have to create software which will outlive most engineers working at the business. You cannot reach the SLOs of google by hacking something together in 2 months!
I was reading https://danluu.com/sounds-easy again today, and when reading this article I was reminded of a particular section:
"Everything we've looked at so far is a technical problem. Compared to organizational problems, technical problems are straightforward. Distributed systems are considered hard because real systems might drop something like 0.1% of messages, corrupt an even smaller percentage of messages, and see latencies in the microsecond to millisecond range. When I talk to higher-ups and compare what they think they're saying to what my coworkers think they're saying, I find that the rate of lost messages is well over 50%, every message gets corrupted, and latency can be months or years"
Dan goes on to say: "When people imagine how long it should take to build something, they're often imagining a team that works perfectly and spends 100% of its time coding. But that's impossible to scale up. The question isn't whether or not there will inefficiencies, but how much inefficiency. A company that could eliminate organizational inefficiency would be a larger innovation than any tech startup, ever."
Communication scales extremely poorly compared to code and large organizations require a very different skillset than small companies. The author seems like someone who just loves writing code as opposed to wanting to deliver maximum business value (As defined by the company), so it makes sense he dislikes big companies.
There are also good and bad big and small companies. A well run big company is still going to have a large amount of communication overhead vs a small company.
Well said. I think the key point you make is that we are paid to maximize the value of the business. If the business isn't profitable, we could all lose our jobs. Too many IC feel that if the company isn't maximizing their personal effort they are inefficient and wrong. However, sometimes more value can be added by NOT writing more code or more documents. It is sometimes more valuable to throw away a bunch of completed work and not fall victim to the sunk cost fallacy. Sometimes a "worse" architecture is the highest BV.
From what I understood, they are talking about the author’s complaint that he doesn’t get to spend 100% of his workday coding/testing/documenting. That doesn’t necessarily mean that the companies were poorly run - larger enterprises with more projects, teams and customers are going to require more meetings.
Maybe he worked at poorly managed companies, who knows. The fact that he was asked to participate in meetings instead of only being assigned purely code-related tasks isn’t very compelling evidence of a company being a “joke”.
I tend to find that where the PO/product job doesnt have to be shared with developers the velocity and quality of the product improves considerably.
I dont think that relatively speaking companies that dont do this are horribly run since it seems to be the norm but I can see why somebody who isnt used to it would rant.
In general larger companies do everything inefficiently. It's to be expected. Small companies wouldnt exist otherwise.
In my view the most effective organizations are made up of mini CEOs.
When you read about organizations which were highly effective there is usually a common theme of management by objective and giving people ownership. “The HP Way” and this speech by Rickhover are two such examples: https://govleaders.org/rickover.htm
> The author seems like someone who just loves writing code as opposed to wanting to deliver maximum business value (As defined by the company), so it makes sense he dislikes big companies.
I think the point is that very little actual business value is being created. This not necessarily due to "actual business needs" but because of deterioration of culture over time and the inevitable principal-agent induced issue of managerial bloat.
Instead of accepting that increased communication needs will slow down everything to a crawl, how about eliminating needless communication? Thats how Amazon does it, and look where they are now.
It's always a worthy goal to try to improve communication efficiency, but it's also the case that a very common failure mode that programmers at the leaves of org charts do not understand what is driving the value of the business they're working in, and have an inflated sense of the importance of the code they're writing (or that they wish they were writing).
But that goes for everyone, until you can put it into numbers which aren't gamed. That's what is being challenged here. Do the communication methods as they exist today provide value, and to what degree? Do we have actual numbers?
Whenever the "we hate meetings / the current bureaucracy" crowd criticizes the current state of affairs, the opposition tends to seek the high ground and go "well but you just don't understand what drives value". Meanwhile, there is a surprising lack of numbers regarding all this.
Ironically, trying to measure this better would inevitably require more bureaucracy! It's a good point nonetheless.
But I'll also say a positive word for qualitative reasoning based on experience being a good first approximation of things. If something gets pushback from a lot of people who have spent a lot of time trying to coordinate large efforts, then it's worth considering that those people may be right. I don't know anyone who has spent a lot of time in one of these coordinating roles who thinks that the primary issue is too many meetings and not enough code being written.
>If something gets pushback from a lot of people who have spent a lot of time trying to coordinate large efforts, then it's worth considering that those people may be right.
It's one thing to consider it an approximation, it's another thing entirely to consider them "right" which is frequently followed with "so we won't investigate any further". Most of us don't live in situations where such decisions are actually critical. We can afford to criticize and experiment. Instead, this line of reasoning tends to be misused and shush any investigation.
>I don't know anyone who has spent a lot of time in one of these coordinating roles who thinks that the primary issue is too many meetings and not enough code being written.
And you don't think that group, much like others, may be a little self-reinforcing?
It isn't "so we won't investigate any further", it is "we don't think it is the best use of our resources to investigate this" and in my view it also implies "but if you have a good idea for how to investigate it empirically, please feel free to do so".
I don't think "that group" is self-reinforcing at all. Essentially everyone who comes in with no experience comes in thinking "meetings are crap, communication is crap, we just need to write code". Most of those people (but not all!) slowly but surely change their minds as they gain experience. But every one of those people is an opportunity for the thesis to be disproven. Similarly, nearly every new organization is an opportunity to try something new. Google didn't start out with lots of meetings and engineering committees and design review processes. They started out just wanting to write tons of code. They didn't hire management (or "agile") consultants or bring in outside managers as they grew to come tell them how to behave like a big company is supposed to. The people who started out writing all that code and ridiculing bureaucracy are the same people who eventually accrued processes to manage meteoric growth.
I really don't think people are as narrow-minded and closed off to this as you seem to believe. People are hungry for a better way to manage organization growth, it's just a high bar because people have seen lots of these kinds of efforts, and frankly just get kind of bored of chasing "one weird trick to make everyone way more productive" again and again.
> it's also the case that a very common failure mode that programmers at the leaves of org charts do not understand what is driving the value of the business they're working in
If that's common and not being addressed, it must not be important. If it's not important, why mention it? Seems like victim-blaming.
"very little business value" is highly subjective. I'm sure that Amazon also has a lot of activities which generate "very little business value" under whatever measure you define.
Don't see how politics or "bickering over the pettiest feature like [...] what colour the chart should be" is what "deliver[ing] maximum business value" is about, as you put it.
The amount of energy and time spent on “politics” or “bickering over petty issues” is usually highly overstated by bloggers.
It’s easy to understand why. The 15 minutes spent bickering over the color of a button will be far more likely to leave an impression and remembered vs the 90 mins spent on ordinary, necessary and useful discussions in the same meeting.
Eh, it's been causing a lot of issues over a long period of time at least in my workplace, and it's been dragging projects that should've been 2-3 days to 2-3 WEEKS.
I'm sure it varies for people (which is why you're downplaying it), but for at least some of us, it is simply the truth, the reality we have to face every day we go to work.
I was having a discussion with one of the people higher up in the org chart about why we need to move beyond a pizza-box development model. Currently what happens is that the CEO (small org, 10 people, he's effectively the CTO) makes small-talk with a dev about a feature that needs to be developed. The dev then goes and builds the thing based on the discussion (a week-10 day sprint), takes the resulting work to the CEO which will then flesh out what needs to happen in addition to the work done. There will be some iterations of this process until the code can be merged into main and the feature completed. It's not horrible really but it can be way more efficient. I'd really like it if we can move beyond this seat-of-the-pants programming and have a more robust documentation process. I've been a part of feature mills like that, I've built my own products (unsuccessfully business wise) and I've also done contracted work. Out of all of these I was most productive when doing contracted work. I think it was due to the customer having to really spell out all of the things wanted in the work product. The requirements analysis was far better than anything else I've ever touched. I don't know why it should be any less detailed when it concerns your own work. You should beforehand be certain that you know what you are about to build. You should state it in a document. The stakeholders should sign off on it being what they want built. All of this takes time and it should. The engineering part of it is mostly trivial. The hard part is building a consensus on what should be built.
That description of "pizza-box development" (unfamiliar term for me) sounds pretty good actually? Seems pretty agile: informal planning, time-boxed sprint, revisit with stakeholder, repeat. It gets so much worse when the implementers are further from the stakeholders or customers. What's the issue there?
I've also worked in consulting and appreciate the explicit requirements, but I find the formality much less efficient than the process you describe earlier. It ends up being very "waterfall" and exactly the approach the Agile Manifesto attempts to counter.
Perhaps you prefer a more waterfall, hierarchical development process, or the companies (big ones) or industries (highly regulated) that necessitate it?
A week-10 day sprint on _one feature_? They haven't drunk the scrum kool-aid yet. Just wait until they do - then every feature will be a "story", and no individual story will be allowed to be assigned more than 8 "story points" (which for some reason means "one day"). If you think a "story" will take more than 8 "story points", you'll be asked to break it down into "subtasks" of no more than 8 "story points" each (you'll be asked to do this accurately in a few minutes in a standup meeting). Trust me, if you tell a higher-up non-programmer that there's anything wrong with the development model, they'll hear "we need to move to the 'scrum' everything-is-mandated-to-take-less-than-a-day development model".
The most successful software company I have worked for used your “pizza-box” model all the time. With 150+ developers. It worked extremely well. The worst software company I have ever worked for spend 95% of its time documenting things and 5% of its time implementing things. It took forever to get anything done.
Not sure I understand the thought behind the statement so apologies in advance if I am barking up the wrong tree, but communication scales beautifully in many different contexts. It's almost like a superpower if done right. I do agree though that poor communication does scale extremely poorly if that's what you meant.
There seems to be unnecessary vitriol towards the author.
What he mentions about big financial companies (where software are for internal workflows) that is the life, and there are many of them and they are usually big employers.
And what he says "You see, we were always busy but seldom productive" is actually the essence of 'Mythical Man Month'.
About FAANG/MAANG, I have seen brilliant college toppers mucking around with html tags (but not able to get them right).
High salaries to a lot of software worker is a joke indeed.
The issue the author is talking about, in my view, is caused by the natural lifespan of corps tending towards bloating middle-management. (Very hard process to fight).
At the start the founder group are rutheless productivity-chasers. Then the corp expands to include the its-just-a-job group. Everything ticks along well, and at some point, the rutheless can't manage the group. So they hire followers to listen to their orders and thereby manage others. In this sense middle management is really "corporate following".
Now you have the its-just-ajobs, rutheless-productives, rutheless-leaders, and leader-followers.
When the corp grows too far the balance in these populations is thrown way off (by, often, the shortsightedness of the real leadership in balloning middle-management to cover for them).
At this point all the meaningful decisions are still held by the exec, but middle management are now so large they have to "find something useful to do", which is regulate all the meaningless decisions.
At this point most of the ruthelessly-productive leave, and you're left with the justajobs, leader-followers and the few clueless productives who'll destroy their mental health trying to grapple with it all.
The gervais-style analysis mystifies some of the issues it describes. The heart of the group dynamics is "leader vs follower", "rutheless vs clueless" and "transactional vs passionate".
A startup is largely "passionate rutheless leaders", it grows to include "transactional ruthless followers" (its-just-ajob), then to "passionate clueless followers" (middle-management). At this phase its highly stable... you hire in "passionate rutheless followers" (ie., more actual workers)... who also need more middle-management... and at somepoint this becomes unbalanced due to poor executive incentives.
That gives you your large population of "passionate clueless followers" (ie., middle-management), and the death of the productive phase of corp. action, into a more rent-seeking (or death) phase.
In gervais, "losers become sociopaths" in a mystifying way; and likewise the "clueless" population is inexplicably unpromotable. My breakdown, for example, clarifies why: the "clueless" population never become rutheless-leadrs as they arent leaders at all. They're followers.
I think muddling "transactional" dispositions with "rutheless" ones also mystifies the issue, under gervais, the "noble sociopath" is hard to explain. Really, its that they're both passionate (internally motivated) and rutheless.
---
NB., rough definitions: "leader vs follower" (I command vs. I am commanded), "rutheless vs clueless" (success requires it vs. virtue requires it) and "transactional vs passionate" (external-reward vs. intrinstic-reward).
I suspect if one were to compare a large number of startups to one large company (or even better a portfolio of large companies), the “ruthless founders” will significantly underperform the middle management in large companies even after adjusting for the inherent advantages large companies have.
The only reason the “ruthless founders” look better is because we usually only talk about the successful ones because unsuccessful ones have disappeared.
Middle management is more successful and ruthless founders are less successful than immediate appearances would suggest.
a business needs an executive, and at scale, it needs middle management to implement the general strategic direction set by the executive
if there are more middle-managers than this requires, they start trying to own non-strategic issues -- which is where you get large numbers of meetings about non-issues
I am 100% sure I can dramatically improve the productivity and bottom line of any software company by simply firing 50% of middle management and using the money saved to hire good software developers.
Why? From his description it sounds like he enjoyed it and that's probably the best kind of work.
I've spent more time on tooling for myself than i got out of it in saved time and learned a ton without pay.
Alternatively i'd have been paying a match of a videogame that i'd have forgotten about by and probably regretted now.
These past days I spent a lot of time doing research into and designing an own keyboard at home. Something similar exists but is imo overpriced yet i'm not even saving money given all i've spent on a soldering iron, etc
But i'm enjoying myself just creating something that i've gotten invested in.
Meanwhile at work I feel like a damn clerk. Making minor changes, arguing, pushing little bits of overhead out of the way and working slowly on something i consider an inherently inefficient design bound to require a complete rewrite at some point for reasons out of our control.
I wish i could go back to those occasional few problems I cared about to work just that bit more to get it working.
In neither scenario I really cared about the overarching company but if there was never ever anything to catch my drive like that i'd have changed jobs by now.
TFA uses exaggeration to paint things which are necessary as superfluous bullshit (write a 50-page doc on every feature). When you strip that, you are left with a pretty banal statement: lone coder outside corporate environment can work faster on implementing stuff than one working on a big project in a corporate setting.
Working with larger and larger groups of people gets harder and big companies don't have all the solutions - fortunately - because otherwise little companies wouldn't have a chance.
I've been in software for 20ish years now and I can tell you that beyond couple of years of learning, there isn't anything new to learn in software. Every few years same old patterns get wrapped under a fancy name and people jump into it thinking it's something cool to learn.
Right? Young devs are just learning at the marvels of static typing languages (python, ruby and type script static typing efforts).and then, "server side rendering" (you mean like, PHP?) and whatnot...
Having been programming for 30 years I find most of it pretty funny.
376 comments
[ 2.4 ms ] story [ 306 ms ] threadThey are optimizing against risk (of change, of loss of control over the whole process from ideating to selling/shipping).
If you can build the product/service in 2 months with a tight focused team of 3-5 people, in a 100+ engineers company, how do you manage if this 3-5 people leave (whatever the reason): how do you manage to infuse their experience/expertise over the thing they built, to 10/20/30 other people to mitigate then this risk?
You can manage to do so when your company grows, because... you don't have a choice, you started small.
When you've grown already, to mitigate this risk, you have to start to infuse things across many people and layers of people you have, so that when, 3-5 people leave, it's almost barely noticeable an event.
Maybe there's a better set of reasons. But this one made me understand better the whole world of big corporations and especially (big) consulting sofware companies (which are often several ones contracted on the same big projects).
Edit: you may also understand "optimizing for" as "scared to death about".
As a case in point, if "when, 3-5 people leave, it's almost barely noticeable an event" then you've almost certainly over-compensated for the general case. Why? Because the entire set of people who know anything about a given project simultaneously leaving should be incredibly rare. If that's your benchmark event probability, and your risk mitigation costs are linear in the risk probability (which they probably are, by vague handwavy analogy to finance thinking), then you're constantly bearing costs that aren't justified by the downsides you're likely to encounter unless the specific project in question is company-breakingly critical.
If an entire dev team up and leaving isn't a rare event, you've got deeper problems.
Yeah they should fix the actual issue many layers above, but that's not something the guy planning for this can do at huge corporations. You just deal with whatever it throws at you.
Worse, people leaving a team are not independent events. People leaving a certain team is often highly correlated to other people leaving the same team, because there is some common cause like a toxic manager.
It happens enough for many (not all) individuals to have noticed across their career (especially when in management, where a big part of their role is already to manage risk).
It happens enough for any single company to be quite traumatized by it when it happened, and to try to avoid it in the future.
Where some companies do it differently is: they don't overreact, they understand that this is a risk management issue and that you can balance it, and/or they don't setup a "general case" for all projets/teams (depending on the type of the project). This requires quite some serenity and perspective.
In most of the large companies I worked for there was zero documentation (+1000 employees, +100 engineers) or very very little or only in a few projects. When people were leaving, someone else was getting hit with a shitty undocumented project, they would spend some time learning it - and that was it. In the worst case a doomed-to-fail-rewrite started and troubled the team for a couple of years.
I think the main issue is that: - People are given tasks from the board of directors (trickling down layers and layers of management), they don't feel like it's their problem - There is little accountability, tracking performance is very hard; tons of companies don't bother, but some of them do (after HR intervention, CTO being in trouble justifying the costs) and they can't find decent metrics to use for performance, so the bosses are basically flying blind / trusting middle managers. - No high growth stocks that will make you rich - Middle managers feeling like they need to prove they're doing something imposing weird and useless rituals: meetings, presentations, etc
These factors allow people to slack off as much as they can and take as long as they can to do anything.
As long as they can come up something for standup, it's all good.
Getting hit with a shitty undocumented or doomed to fail project is part of the problem/risk being managed or not: on some occasion, it can kill the team/project/company, on some other, it can be managed more or less successfully, but still in a way that is _not regular_ against the baseline.
When you get a project handled by a larger team of people apparently doing "not much", 1/2/3 of these leaving will not change the baseline of the project they were working on (or if it does, then comes the pressure to reorganize again to avoid that disruption).
It's "a bit" similar to the 40% lazy ants thing (https://boingboing.net/2017/09/12/living-larders.html).
1. a unicorn where someone implemented a a CI/CD system that none else can work with nor comprehend
2. a public institution where dozens of people work against the clock to replace the software maintained by a few old farts close to retirement
3. a critical financial institution where secrecy and nepotism made anyone with 30+ years of service into a major failure point.
IMO, the bigger the organisation, the more they are shifting from internal risk management to outsourcing all risk. When the risk is handled by third parties via contractual obligations, life get easy for middle management.
Needless to say, many of those contractual obligations are not worth the paper they are written on. Many organisations survive largely on the good will of the lowest-rank employees.
You get all these defenders coming out of the woodwork when people wonder what the hell all the programmers at say, Twitter, are doing. Supposedly you puny mind can’t comprehend the challenges of developing a website “at scale”
The real answer is, almost nothing. People are being paid very high salaries to do nothing.
But in a badly managed company each person is like a randomly oriented vector.
You sum them together and the end result is something near to zero.
On each of my job in my early career, I spent considerable effort weeding out people who got too used to such mode of work.
There are software developers with vastly different prior work experience, and expectations. People who do 30 minutes of actual coding a day, and ones who do 11 hours in coding sweatshops.
People who spent their entire career on 30 minutes of coding a day jobs, and think of themselves too much once they rise in seniority are the worst, and are the biggest source of dumpster fire/death march projects.
My third serious job in Canada: work in a consumer electronics trading company, upgrading their shipping system to get shipment status from DHL API, and submitting new ones. My predecessor, and ex-unit head wasted close to $1m, and more than a year, got SAP involved, invited many consultants, change managers, a project management contractor, and just been in the process of "fixing deficiencies" of his work by buying "enterprise SOA solution."
23 year old me called this bullshit on the second week, fought to have a serious talk with the company owner, rewrote a 10 years old steaming pile of PERL, and BASH scripts to Python, Postgres, and JS frontend in under one week, showed it working, and countered "You don't understand SOA!" protests of the unit head in front of the boss. He gets fired, I get a bonus the size of my annual salary.
Since then, my bosses always threw me as a "firefighter" on projects in crisis.
------------
We now have 2 major trends in the industry:
1. More, and more non-IT companies are trying to do software
2. A giant amount of newcomers to the industry who would've normally went working for banks, and management consulting companies eroding big IT companies as later grew with little regard to quality of hires.
I wouldn't recommend it though since it's soul crushing.
The amount of actual lines of code written by an average SWE at a BigCorp is miniscule. The amount of churn and spinning and hand wringing that goes into that code is staggering. But it's like that for a reason. There's just a lot of people.
It's torture, and in order to maintain productivity you need to have about 5-6 of these processes running concurrently, and it's why you get paid a lot of money to do it.
Do poorly at juggling that and making "progress"? Find yourself on the receiving end of a performance review where the label "meets expectations" actually means "you better start kicking ass at this, or you'll find yourself with no stock refresh grants for next year."
All the money and free food and so on is just a salve to try to make the whole thing less unpleasant. Some people get a high out of the process, while it drives other people slowly crazy.
(In my last months at Google the only part of the job I "enjoyed" was the week I was on-call for the first time on my new team. Because it was the only time in over a year where I felt useful even though it was quite stressful. That's how I knew it was time to pack it in)
https://goomics.net/364/
They don't have it easy either. They have to demonstrate at least once a year that they've "accomplished" something in spite of an entire organization of gates that make accomplishing anything nearly impossible. But they still have to figure out a way to do it, and it still has to be somehow represent enough to justify their pay.
It's like something like AWS or Azure. You can provision and deploy a K8s cluster? Awesome! Now, can you do that consistently for the next 100 thousand K8s clusters you're selling to your clients?
It's a very different kettle of fish.
My experience at a tech company with around the same number of employees is that it actually feels understaffed in some of the areas I've seen. It's surprising how much responsibility some teams have.
I know it sounds counter-intuitive, but software doesn't really scale linearly. Unless they're 100% independent, the communication overhead will always be there. Fred Brooks and all that.
With 7000 developers working in a connected system, it probably feels slower and less things get done than if there were less people.
It's not simple to go back to having less people, however. The architecture is most certainly tied to the organizational structure (Conway's Law), and firing people will make it worse in the meantime.
Also, software development teams have to assume more responsibilities just to escape this communication/interconnection overhead: devops is a good example, you no longer have to depend on another team, but now you gotta do operations yourself. An example of avoiding interconnection overhead is having isolated services: now you don't run queries on team Y's database, but you still have to maintain that data on your own DB. Isolation is a good alternative, but it also has its costs.
Unless we're talking about 7000 software developers working on 400 completely different and completely isolated products and answering to different people, there's gonna be a lot of invisible communication overhead, or overhead because of the need to work together with the other 6999. We developers tend to abstract it as being "part of the job", even though it is definitely non-essential complexity.
Even consulting companies doing different projects can fall prey to that: I know lots of cases of internal frameworks/libraries/UI-toolkits being adopted to accelerate development, but they ended up being a bottleneck in development because the team that owned had a full backlog.
Took a FT job at a megacorp a few years ago and assigned a new project - I read the specs/requirements and in my IC mind thought to myself - if I was hired as contractor to develop this tool, how much would I charge? and how long would it take me? - and came up with 1 person, for 2 months, and would have been delighted to be able to bill $40K for it, but probably would have went it at $60K on a fixed bid (I always preferred fix bids).
Of course this wasn't a project I was bidding on, I was just the lead dev - the company pulled together a team of almost a dozen people and a budget of just over a million dollars with a 8 month timeframe to get it done - they also budgeted another $120K/year to host it when it was done on multiple big servers in the internal data center.
We spent the full million dollars and got it done - I did however have one small win and pushed them to micro-services solution in S3 and Aws Lambda and got the whole thing to run within the free-tier of an AWS account.
If you ever start a small software company, don't ever hire people that have only worked in large enterprises - they just don't know how to get things done cost or time efficiently.
Anyway, it seems there is just a lot of money to go around and political and social favours dominate a lot of the decisions.
Trying to parse your definition of the term, as it seems like any definition for communism disrupts the feedback mechanism that is a free market's primary (only?) advantage.
It's a free market but with the financial incentive system removed, but maybe social/status/religious incentive retained. Everyone does what they want but at 100% tax rate and the product is shared. Of course this only works in IP because it has zero marginal cost of consumption (and taxation!). In meat space you have the political problem of how the fruits of labor are distributed.
I think history has born out how FOSS incentives get entangled with a primary and majority patron.
If you're interested, Peter Kropotkin wrote a lot of books and pamphlets that are freely available.
With an addendum: it's not that they do "nothing", and that's the "problem". The end result is minimal, but the amount of work is still significant.
In any saner place it would amount to almost nothing, but for certain companies it is an Herculean task. And developers know it.
However due to the fact that the company hired thousand of coders, their communication overhead is now too massive. Their architecture also suffers due to the needs of handling those thousands of developers, so there's also a lot of work to be done in coding.
But the pressure is still there. Why hasn't your team changed the color of the button yet? "Why is it so hard?", "Why is it taking so long", etc etc
Jokes have been made about it: https://www.youtube.com/watch?v=y8OnoxKotPQ
The answer to all that was known since the 70s. Fred Brooks wrote a great book about all that.
I'm patiently waiting for some kind of deep-dive historical monograph to be written in the 2050s. What I suspect may have happened is that these companies overhire top talent simply so their competitors can't have them. For the actual work they do, it's massively overpaying. As a strategic investment to prevent said talent from working elsewhere or starting their own business, perhaps it pays off.
I think it is like brand name vs off brand. I just bought off brand oatmeal that was $1.98 vs the brand name was $3.50.
Someone buying the brand name is just operating on an unthinking heuristic that they only buy "the best". I am sure they would justify it after the fact that the brand name taste better even though it is just oatmeal.
So many decision points in society run on that heuristic IMO.
The author puts it better: they do lots of things, all day long, but produce almost nothing.
People are being paid very high salaries to be frustrated by explicit prohibitions on doing anything. Nobody gets to being good enough to be hired by a company like Twitter if they don't actually want to do real software development - management exists to crush that desire and ensure that nothing ever gets done.
The writing is smug and shows no self awareness - it seems to me that the author cannot recognise that there may be other priorities than exactly what is in front of them and therefore everyone who disagrees with him must be wrong.
It is good that the author has found something that suits them better.
What you're missing is that doing soft tasks is a tradeoff and big companies are leaving a lot on the table by having an inflexible culture.
Those same big companies will end up buying startups for 10x their ARR to get some mediocre product with no documentation or tests, cranked by developers on redbulls swearing at each other instead of doing retrospectives and yoga friday.
And yet, that mediocre product still is orders of magnitude better than what the big-co would have been able to produce internally, simply because of all the ass-kissing and butt-covering involved in big-co office politics.
But what if engineers are writing bad code? What if their code doesn't solve any customer problems? What if the other thing they're doing is helping them write better code? Or scaling the company so they can hire other engineers who do write better code?
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
Sounds like an environment the author of the post would like, he even describes such an environment later on, one that he enjoys so much he overworks for no extra pay.
Then there's the twelve principles, one of which is:
"Working software is the primary measure of progress."
Another one is:
"The best architectures, requirements, and designs emerge from self-organizing teams."
Another is:
"Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done."
Following bullshit company processes and pointless meetings is the opposite of the above. The one that might be contentious is:
"Business people and developers must work together daily throughout the project."
This sounds a lot like meetings, but that's the smallbrained take on it. Here's an easy alternative: Continuous Deployment in a staging area and a Slack/Teams channel for business people to comment on changes they feel are necessary. Not only does the request get recorded (often nothing gets documented in meetings) but the communication is asynchronous and doesn't require booking the entire team for hours. The discussion is also a lot more actionable because it is about something concrete.
Given the above, what do you think about how an author of the manifesto would respond?
Hired my own team of devs. Got no revenue, velocity was low. Ended up annoying all the devs by trying to push them to spend more on the right-hand side of the manifesto than they thought was necessary so I could figure out why nothing was getting done. Still got no revenue. Eventually gave up.
I think the authors of the agile manifesto would say that building complex software requires the business to adopt agile (real agile, not half-arsed agile) with the tech team subsequently following it. The engineers also need to deliver on their side of the bargain. That means continous value, and not just fiddling with shiny new tech and fancy design patterns. When both sides of that operation work well together, you get good software. If you've got enough good people that already know how to do this, it bodes well. But how do you find and pay for all these good people? That's why you get people that merely think they're good, but are at least much cheaper.
The engineering tendency when given freedom is to over-engineer everything, leading to disappointed clients, and a fragile system that's buggy and can't be fixed. It's one of the big reasons so many tech-led startups fail, and also why bigger businesses end up putting all these bullshit processes in place.
And that's my take on the OP. Lots of "managers bad" without recognising the faults of engineers in that process.
"Design Patterns" and the latest "Web Framework" fad are the opposite of delivering working software. How you find people with the right mentality? I'm not sure.
Low-level game devs tend to have that "make it work" mentality but they like to reinvent the wheel a little too much because the existing wheel is 0.1% slower than their custom made one.
Web devs are the opposite, they seem to think the wheel has manifested itself from the ether. They probably don't even know about half of the 50 wheels they brought into the project, and they'll replace them with newer, shinier wheels in a week.
I think hiring a good team lead with the right priorities is key. Not a "manager", but the team member everyone else looks up to and follows out of their own volition. It might be worth wasting a lot of money and time on finding and hiring that person at the very beginning. If you do, the rest should fall into place, as they'll hire people who work well with them, meaning same priorities.
Look at the impact someone like Jim Keller had on the companies he worked for, as an example.
Finding people with the right mentality is, as you say, very hard.
The temptation of the manager is to get people with the wrong mentality and wrap them enough process that it will fix them. The temptation of the contributor is to blame the manager without looking at their own faults.
As good a solution as I can suggest is to work with people who are willing to collaborate on a positive outcome, and go through genuine continuous improvement.
I've also had to deal with the "bad" manager that gives no push (nor any time) for stabilization, leading the code to a near-project-killing state of constant malfunction. Quite a few of the principles in the manifesto are about avoiding exactly this state, but they too are not followed correctly.
The following are in a different order in the manifesto, but I think this should be the way to read them, they almost form a coherent paragraph:
"Continuous attention to technical excellence and good design enhances agility. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely."
This means quality needs to be considered from the beginning and maintained, but that's not contradicting the fast delivery, quite the opposite (proven by many studies on Continuous Delivery).
Quality arises from constant refactoring the working code to be better, based on the results obtained from seeing that code running. Not from planning ahead with some insane micro-service bullshit architecture 3 months in advance for a project that probably will never scale to a size that needs that nonsense (at which point you deal with it).
But you have to give time for that cleanup work, and introduce a culture that demands that quality (where quality is measured by the software working well and delivering value, not by how theoretically "clean" the code is) otherwise it simply won't happen.
I've also had to deal with the "good" manager that tries to fix the above issues (after they happened) with processes. In my experience they just slow down velocity and don't resolve any of the actual problems. It's like telling a plumber that is almost swimming in shit to read and sign a 20 page document before turning off the valve of the pipe that's spewing brown liquid everywhere. That plumber is just going to hate you.
The only thing that works is to demand both continuous delivery and consistent quality (and allow time for the latter at the expense of the former if need be), ensure you have the right lead, communicate openly and regularly, and then let the team do its thing. If the devs and PMs don't see each other as allies rather than annoyances, the whole thing falls apart.
Also all it takes is 1 bad dev to spoil the bunch, I've seen them do so much damage it's nuts (stuff like introduce some whole new web framework nobody else in the team knows on some part of the project, or rework entire parts of the code to be async even though then it doesn't work with the rest of the codebase). Code review / pair programming is supposed to prevent this but if the team lead lacks the strength to keep devs like that in line, you're screwed anyway.
"Individuals and interactions over processes and tools"
If the individuals and interactions are wrong, no amount of processes and tools will fix it... I guess companies the size of Microsoft and Google can throw enough money at the problem that things work out somehow, despite the abysmal quality of most of their software.
Something tells me he’s gunning for that Medium paycheck.
I'm sorry, what? Out of the loop here.
But basically: outrage increases readership increases Medium author payout
How many Heartbleed, left-pad or whatever similar instances of catastrophe does the IT industry need to recognize that relying on self-exploitation and intermittent government grants is not the way forward?
As the old saying goes, "you can save hours of planning by doing weeks of coding."
You then have to spend a significant amount of time trying to guide people to focus on the right things. And that is draining.
- the code, obviously
- infrastructure
- documentation
- wireframes, mock ups
- user manuals?
- monitoring
- ...
Software engineers shouldn't be the ones who address all the points above (otherwise that leads to burned out developers like the author).
You are mentioning perspective and priorities. But from what I know these are exactly the problem. The more people you have that are disconnected from production and use, the more BS work tends to get generated. Not only because of increased bureaucracy and overhead, but also because decisions get made by disjointed actors and are often based on buzzwords or company politics.
The article's formulation:
> You will be asked to write a 50-page documentation for some little code you wrote.
The author does not complain just about writing documentation, but about writing an unproportionate amount of it that presumably isn't being read by anyone. I've seen that happen. People writing essays about software that are bound to get outdated and will never be read by anyone. In systems that are disconnected from the source code.
> The writing is smug and shows no self awareness
Maybe I share the author's disdain for the corporate setting, but I don't see the smugness.
While the article may not acknowledge the cost and value of doing things slowly and bureaucratically, I fail to see how that is an expression of lack of self-awareness. It is mainly an expression of a preference for seeing direct change to business logic in a short amount of time, even for aging projects, because of direct ownership.
This has been the norm more often than not in most companies, especially larger ones. Hence the Agile Manifesto, written by people who've been there again and again.
Because end result is that no one knows how to use our own software. You dont know what it is supposed to do, so it is impossible to keep that stuff working. It takes ridiculous amount of time to configure anything or reproduce bugs, because you need multiple calls to find the one person who barely remembers.
Also agile manifesto is 20 years old. Agile is literally what most large dysfunctional companies do these days. It does not have no new solutions to actual real problems of companies, because it is old.
The comment I replied to says "inappropriate amount of documentation", the Agile Manifesto says "comprehensive documentation".
That's the problem. Months, if not years, spent on pages after pages of comprehensive documentation that does not add any value and is obsolete by the time you start writing actual code.
Lastly, the age of something is not a relevant criterion. Not much has actually changed over the last 20 years. What has changed is the explosion of web-related software, which is actually the best suited for the ideas behind the Agile Manifesto.
This picture is not any real company I ever worked in or real company I heard of from friends. Literally, not even before agile manifesto.
> Not much has actually changed over the last 20 years. What has changed is the explosion of web-related software, which is actually the best suited for ideas behind Agile.
That is not actually true, really. A lot did changed.
And in small corps, there's the "guy who wrote it" was "hit by a bus" scenario. It doesn't matter how dilligent, or how faithful someone may be when they leave, eg walking a replacement through the codebase can't happen of you're dead!
This is how I document. I think about being hit by a bus, and what would this corp do? A replacement hiree do? See?
Not doing this is, IMO, should be criminal. Like a CFO not keeping books.
I write a lot of documentation entirely with the awareness that no one else will read it. I write it for myself. I don't want to have to remember the intricacies of a system. I want to write things down, then move on immediately, and have the security of something I can refer back to if I need it when I revisit the system.
I am required to in the sense that I define the policy about what gets documented on my team, and I said we write documentation about everything.
Writing code is more about communicating how to solve a problem than just solving a problem, that's how I view it. If you don't communicate, nobody except you will ever understand it. It might be that you don't need to document a lot, maybe most is obvious if the key parts are sufficiently explained. But it's vital and sometimes it's better to write a bit more than a bit less. A thing is, outdated documentation might be worse than none, so it's a delicate balance.
Yeah, documentation will definitely help in this case. With it, you can swap teams and even companies, and it still works! This only fails in companies which do not review documentation and have no routine for keeping it in sync and testing it on e.g. newcomers, like you do for backups. Cause otherwise it is as good as never tested six months old backup.
EDIT: It might have even been fortran code. The rest of the project was C++
This is an interesting case, because it's something that I probably wouldn't document. Code should be readable. If you're writing down how your code works in a document then something is wrong with the code. Documentation can't fix an incomprehensible codebase. I document how algorithms work, what the business logic is for things (which is another algorithm really), how applications work in a 'data flow' sense, what integrations there are with external services and how they work, what things mean, and so on.
I've encountered this "readable code means I don't have to document" idea before. I have no time for it, it's just wrong:
1. Important things aren't easily visible in the code, most commonly why the code does a particular thing. "Readable" code, which is a very subjective standard, can only tell you what it does but not the underlying rationale.
2. Writing docs often exposes the fact that the way the code works, or is expected to be used, doesn't make sense or is sub-optimal. If your docs include lots of caveats or explanations of nonsensical behaviour then it's a good hint you should go back and think again.
3. Figuring out stuff by reading the code is often drastically slower than reading the docs. That's why all professional APIs have good docs and people grumble and moan when expected to use code that doesn't.
4. The sort of people who argue this, in my experience, often don't actually write readable code, they just tell themselves they do.
Then, when you land in a corporation you can see how large teams barely manage to match your former personal productivity by choosing wrong technologies, taking wrong approaches, discussing irrelevant things in countless meetings and producing tons of write-only never-read documentation that gets obsoleted almost as fast as it is written. If you are too youthful and idealistic you can get a little arrogant experiencing this inefficiencies when you have a context to fully appreciate their insanity.
Or you may take another approach. That efficiency actually doesn't matter. People don't work to achieve anything. They work to get paid. And corporations have a lot of money. So the game is no longer about building stuff efficiently. It's about raking in as much money as you can for as long as you can and every inefficiency that justifies further work is actually best friend of everybody involved.
You’re describing the goals of the individual becoming divergent from the goals of the company.
In the article the writer described his team’s goals at the VFX software company as being well aligned with the goals of the company and the customers. They even stayed late because they were enjoying solving the problem so much.
The same misalignment in goals is what made Communist Russia so awful. The stated goals were about providing prosperity to all workers and citizens of the USSR, but the goals of the committees became about personal advancement and the preservation of the party. It could be argued that the extreme job security of the dictatorship allowed this situation. If there had been a way to democratically fire officials, they would have been more aligned with the goals of the people. (A politician is only as good as your ability to fire them.)
Many large companies end up like the USSR. The way to solve this is to allow teams to fire their managers.
I don't follow. Wouldn't most teams replace their manager with a manager who would give everyone the biggest raises and the easiest working conditions?
Why would a team want a manager who cares about the goals of the company?
Bind their avaiable budget to their success.
That is fine, but now you are stuck playing politics. You have to keep whoever is in charge of the money happy. And no value is created because everyone is trying to avoid getting blamed for problems.
Obviously, real companies, making real software also have to keep customers happy, but at least those requirements are somewhat predictable as they are tied to the real world use case, and real world value customers are getting from the product.
"Delivering a product that solves end user needs and is as maintainable and reliable as possible" is the only truly important thing, and only some of that is code.
Meetings generally aren't for developers. They're to keep everyone else involved with the project sync'd up.
Do I and every software engineer wish we had fewer meetings? Absolutely. Do I recognize that meetings are valuable to people not me and are critical in helping them deliver their (often non-code) parts of the project? Absolutely.
Not recognizing that after 20 years in the industry is baffling.
I'd be curious if author has ever worked on a large, 1 year+ project that went awry because the requirements were incomplete and the end users' needs poorly understood. If so, then I'm not sure they took the right introspective lessons away from that.
Edit: And I recognize that some companies are incapable of delivering software, due to broken development processes. I've worked for health insurance companies and know how baroque it can get. But that's been the exception rather than the rule.
Sometimes being quick to market is more important then having to maintain the product. Sometimes providing a bad product is only relative to the competition (which may have a worse product). Sometimes having a good customer service is more important than the reliability of the product. etc.,.
I do agree with solving the end user needs... if a client does not need your product you really can't run a company for long.
Eventually will came someone with a truly good product and distrupt the market
In some fields having a good business and regulatory relationship with the customers (e.g., hospitals, DoD, banks, etc.,) is much tougher than building the product. There are many barriers in place and these fields are not so easily disrupted (having a superior product is definitely not enough).
Also note that having a bad product now that is better than the competition does not mean you cease to improve.
That is popular opinion among the unemployed, as hoisting that BS on your project lead has real world consequences after your code audit. =)
They want it! and they want it now!
The head engineer says it's all just a temp hack, it is completely shitty, they could give it to costumers but then the maintenance will be impossible, they will need months to add any new features on top of it, they will probably waste all their time on fixing bugs, and they'll quit if they have to maintain it for long.
What would you do? (A) continue develop until you have a nice maintainable product, or (B) sell the product now and face the consequence of wasted developer time and loss of their motivation.
Sometimes in such situations the answer is (A), but not always. It depends. How much money you got? how certain are you of the timeline for "finishing" the product properly? which option is riskier? How much competition you have and how likely they are to publish a product before you? What could having a real customer teach you about your product? What do you need in order to get the next round of investment?
This is just an example, but IMO product graveyard is filled with great maintainable and reliable code no one had a chance to use. I love software and I'm really not disregarding its importance, I just think it's not always the most important thing.
I will tell you a terrible secret of successful software companies: "One doesn't make money writing software, but rather reselling the same software mullions of times over."
You should know this already. =P
And I do have specific real cases from my experience in mind... One of a great product that never finished (money ran out, CEO didn't want to provide something that was for "a single customer" as in your words), another of a shitty buggy unmaintainable software that did grow a company from 4 to 100 employees then to an exit and only then came the nice eased-back rewrite.
I have culled many half-arsed options... and the decisions are far from arbitrary. Also, who budgets for a project burning over $100k a month in labor without a detailed plan... lol
Start-up have terrible survival odds. Decisions should not be arbitrary. There should be a detailed plan.
1. when two people are "talking past" each other.
2. It isn't only about 'what I'm saying'; multiple streams of conversation can happen at the same time and all be useful and even true
Groan. This comment could make its point without assuming what the other party knows or doesn't.
For example, for many engineers, what they (a) can learn and (b) be proud of while building a product is a big part of success.
For some CEOs, engineer satisfaction is only a secondary or tertiary goal -- their business success crowds out most other things. This is complex; sometimes this drive is what helps a business succeed; sometimes this is why people get treated poorly or ethics go out the window.
As this is mostly on-topic for the parent thread... I can respond...
When faced with a painful product launch/schedule, as management messed up resource budgets etc... there are a few actions one can usually take:
1. ignore the issue, accept a 60% probability of failure risk, and naively hope management is replaced
2. adjust current project scope, follow MVP rules, and defer features for v2
3. cull the project, and eject unprofitable/unhelpful members from the team
4. Leave the company before the shite hits the fan
Note, compromising workmanship is not on the list, as a business "Brand" is often more important than non-stakeholder opinions of intangible asset valuation.
> Delivering a product that solves end user needs and is as maintainable and reliable as possible" is the only truly important thing, and only some of that is code.
that it should also bring money, or enough money, to be more precise.
It may sound strange but lots of products that fall on your very on-point definition fail to bring enough money in order to keep the lights on (and then some), this is a point that gets lost on many software developers. For context, I've been a paid programmer for 15+ years now, mostly in small companies, maybe as part of bigger companies/projects the view is a little different and "bringing in money" is not seen as that important for the developers.
> And this isn't to say that some companies aren't pathologically incapable of delivering software...
"isn't", "aren't", "incapable"
Three back-to-back negatives have me confused. Somewhat mysteriously, I (think I) understand what it means when I read it quickly, but if I pause to think I get confused. English isn't my first language :)
Update: Thanks for editing to make it clearer!
IMHO, "this isn't to say" is a common expression in English, so I didn't register it as a negative. But you're absolutely correct.
For example, some people say statements like "I don't want no towels".
What they really meant: "I don't want towels"
What I get if I cancel the negatives: "I do want towels"
The meaning flipped :)
It's technically incorrect but common English.
If I say 'proper nouns have a capital first letter' I don't think 'actually oliver sometimes people don't do that' is helpful.
We don't need no education
I'm sure it happens reliably somewhere, but I'd hazard not at most companies.
Consultants only seem to get called in after things have gone wrong too so does your experience support that not doing this is bad practice?
Setting aside the "This company was fundamentally disfunctional" cases, my takeaway has been that knowledge gaps between roles are an underappreciated cause of bad development outcomes.
Writing requirements is hard. Writing requirements without some intuition of what developers need to know is harder. Writing requirements without context on the business domain is harder.
So the ideal BA is someone who is a developer who is also experienced in the business domain.
The majority of companies don't want to pay enough to hire BAs with that experience.
So you get users (who may know nothing about software) + minimum cost BA (who is doing their best, but has no context for anything) coming up with requirements, which are of course incomplete and/or incorrect.
But fundamentally this problem is too large of a skill/knowledge gap between the user and BA, and between the BA and the developer.
Which is such a weird perspective to me. The point of writing software for business is to solve a business problem. Maybe it's a function of working in small companies and/or roles that straddle code writing and business, but I have a hard time writing good code unless I know the business problem space.
It's also why I think I don't get too worked up in the language arguments. I've written code from VB5 to Java to Go to JS all which deliver immense business value. When I think about the best code I've ever written, I don't think about how pretty it was or even the language, but is it still in use 5-10-20 years later.
As a pathological counter example think about arcane obtuse code that people are afraid to modify.
If you find yourself empathising with the author, you really only have two choices:
a) Quit, do something else for a living, enjoy your programming in your spare time
b) Suck it up
Even rock stars have to sit in meetings and do things they'd rather not, like hold press conferences, give interviews, etc.
However, I understand that a project is documentation and future planning, too. So, I want to build an artifact complete with its documentation, which can be sustainably moved forward by anyone other than me.
If I don't document what I've coded, then the joy project becomes a weight on me, and prevents me from moving to new, bigger things. Also, I can show the whole shebang as "I made dis!", and anybody can have an idea what the project is all about.
I rarely have meetings about things are not entirely technical, and I actually enjoy the meetings we have as we always come up with valid points that one alone may not have considered.
Anyway, just wanted to mention my experience as I don't agree that as you become more experienced, you tend to write less code. I am as productive now as I've ever been, even being one of the main and most experienced developers in a team of 20+.
As it comes up here from time to time, I work as a sysadmin, and have my side academic gig, which I'm the solo developer on a serious piece of code. I design, code, test and verify the whole thing, which is immensely satisfying.
My daily job is very connected to my academic gig, and they feed each other. As a result, I can apply what I've learnt from one to the other. We're a small team, doing a lot of big things, hence my work environment is drastically different than yours.
The gist of my comment was actually, "As I get more experienced, I design and write less code because it's more correct from get go. Then I document it at the level needed and I have something concrete and which can be passed over to anyone who wants to maintain or fork it, and this is equally, if not more satisfying".
My experience is very similar to the article's. I just draw a very different set of conclusions.
For risk averse, cost constrained, low stakes projects.
Good engineering work is neither demanded or required..
My viewpoint is simple.
Don't work on software nobody cares about.
Work on software that's doing something genuinely important.
Then people will feel obliged to cut the meetings short and be more efficient.
I don't see how I should square that statement with your next:
Don't work on software nobody cares about
How do you know what software people care about unless you spend time working with the stakeholders?
"Is the high level goal for this software critical."
If yes. Then, people will give the problem the full attention it deserves.
And once you have their full attention, you are more likely to get their cooperation to being actually productive.
If no.
You're going to have a bad time.
But if every project has non-developers deeply involved in them then the software is very shallow. So to me anyone who thinks that every developer needs to be involved in such meetings just shows they have never worked on anything deeper than a crud app with some basic business logic. If you work on anything like a compiler, a garbage collector, a database engine, a load balancer, any kind of software framework etc then you will have plenty of teams never needing to talk to non-developers.
Replace non-developers with "people outside your immediate team". In a developers-all-the-way-down shop, there are still people who are intricately dependant-on but not involved-in your work.
Being a logical, cooperative, well-communicating human being is not a requirement to be a developer.
If your company is fine with them being unable to communicate then your company obviously is fine with you not being able to communicate as well, so why try? And if your company hires people who are good at communicating then there is little need for meetings between developers except politics, and most developers shouldn't have to deal directly with company politics.
Wow. This looks like a quick and harsh over-generalization. This sounds like a pretty deep-seated lack of understanding.
Baffing, cognitively?
Or is this a value judgment?
Have you observed human nature particularly in the last ten years w.r.t. echo chambers?
So if you're in a position like that, assert yourself and your presence in meetings; do you have valuable input that they need? Is there a time set, a concrete goal / agenda? If you don't have to be there for any other reason but to be kept in the loop, can they just send a tl;dr?
I mean I get that a lot of things need to be discussed - and a subject like chart colors can be reused for years after the decision was made - but not everything should be an all hands meeting. Have the least amount of people in a meeting to come to a decision and keep others in the loop. Let everyone do what they do best.
Learning to use search features should be a good step as well. Outlook has search, Azure DevOps has search, there's Google, and most chat programs have search as well. Some developers need to learn to use these too.
You don't have to be a wizard at search engine flags or features or anything - it just needs to be the first thing you do to avoid shallow, easy-to-answer questions.
s/would/should/
The real benefit of those forms of communication is that you have a written, hopefully searchable, record of the discussion. It also forces people to mold their incoherent thoughts into complete sentences.
Meetings should be reserved for brainstorming and decision making.
Many meetings can indeed be emails. Developers tend to be only so-so at identifying which meetings these actually are. And developers are terrible at identifying which two week long email threads could have been a short meeting.
It isn't enough to say "there are too many meetings" and be done with it. You need to identify which meetings can be removed - and that can be tricky.
Those meetings that are simply "status story time" where someone reads a doc to the room? Yea, they should be removed. I don't think anyone likes them.
If I have to help them with everything, why don't I just talk to the users directly and write the requirements myself? It would be faster, and can even save the paperwork. This is modus operandi for contractors.
Why do I have to drag along these type of bozos all the time, and suck up to them like they are my masters. Cut the fat and get rid of the useless bureaucrats. Or at least get rid of this stupid "rank" that programmers are "the bottom of the food chain" so they can at least root out the shitty PMs.
Nobody complained when Steve Jobs delivered much more sharp-tongued rants than this article.
> Nobody complained when Steve Jobs delivered much more sharp-tongued rants than this article.
What are you referring to? Jobs alienated people all the time, people quit their jobs over things he said.
I gotta disagree: "Delivering a product that solves end user needs and is as maintainable and reliable as necessary" is the goal.
Getting five 9s uptime on something that needs only 99% uptime is pointless.
Definitely. This style of writing immediately put me off the rest of the piece. I've worked with software engineers like this, and it's no fun.
There's a difference between "writing documentation that fits the need at the moment" or "write fifty thousand pages of documentation no one will ever read, just to check a checkbox on some manager's checklist / compliance requirement". Or endless "sync" meetings that are effectively nothing more than filling the desire of managers to (micro-)manage.
With a decade of industry experience from freelancing over small agencies to big-corp/government jobs I've worked, I can say this: The core problem at the root of most big-co/government projects and associated disasters is that there are way too many levels of "deciders" and especially a fundamental lack of trust in people to do the right thing. When everyone is just in cover-your-ass mode and no one is willing to risk making a decision that is not backed by weeks worth of analytics and big data, shit will hit the fan real hard sooner or later.
The most successful projects are done by startups or in the big-co world where a significantly high-up person says "we're going to deliver a solution to the problem X" and everyone is focused on reaching that holistic (!) milestone, not on micro-optimizing their KPIs, OKRs or other bullshit. The key to success is trust, the focus on one shared goal and actually paying enough to hire decent seniors to lead.
Some engineers are allergic to teamwork. I deal with coworkers with a similar attitude on a daily basis.
The most frustrating aspect of it is that companies are usually bad at acknowledging someone is a bad fit for a project or a team, even when they are shown solid evidence.
A big part of it has to do with how broken the interviewing process is - the focus at the moment is almost entirely on coding exercises and ignore tasks that many developers perceive as boring but can be crucial, such as writing documentation. It leads to mixed results where you end up hiring some engineers with T-shaped skills along with absolute code monkeys.
There is no real excuse why when you're paid to code you're not doing that 4-5hours a day at least 5 days a week. Career development is one thing, but there are 7 working hours between 9-5 so if someone wanted to work on that they have a full 10-15hrs a week excluding a break for lunch. Lets take out 5hrs of meetings a week which is still likely too much to be productive and we're down to: ~10hr for personal growth, ~5hr for lunches, ~5hr of meetings to keep people up to date and 20hr of actual work every week out of every employee.
Some meetings are important. Most are not. This is another common problem that middle-management gets into. Constant cracking of the whip and arguing-about/discussing small details is just toxic to productivity. (Small here being what style/color/toolkit. Not knocking up a prototype and pivoting when needed based on strategy and risk analysis performed at the start of a good project).
Most "divergences" or decisions can be worked out through a SWAT analysis (yes I'm quoting Scilicon valley), or by managers making decisions and pissing someone off some of the time rather than holding everyone back all of the time.
I've worked for managers with both management styles and I can guarantee the boss that makes a decision (even if it's wrong) is better than the boss that holds 5 meetings on the topic, because often you'll either get over it and move on, or prove it's wrong by the 2nd/3rd meeting and will still be ahead of the 5-meeting nod-fest.
This mantra of hire more bad coders or letting talented coders go to waste because they're not being allowed to do their jobs is adding to a huge bubble in the sector and frankly, on the precipice of a major recession I think people in such companies should be starting to panic.
Alongside this we also have: open source is inferior because of... reasons, something about older developers ageing like fine wine unless they work as web developers with all of those young whippersnappers learning new JS frameworks every month, something else about maths and algorithms but is really about Big O Notation being bullshit.
Not to dismiss the author's point: I'd like to believe they're being genuine and not just being controversial for clicks. But they have quite the chip on their shoulder it seems.
Also, it is quite amusing. I do enjoy the occasional rant.
> but complaining about needing to do documentation
Here is what the blog post writes:
> You will be asked to write a 50-page documentation for some little code you wrote.
The parent post (^) misread and mischaracterized the blog post. It is notable that the ^ called the other author 'smug' and then proceeded to respond to the least charitable interpretation.
> Obviously there are inefficiencies with big companies, but complaining about needing to do documentation, or basic project management?
This sounds like you've never been in a big org where you write more word docs than you do code. I have. It was terrible for a few reasons:
* Those docs go out of date with the code very quickly and so are not a good reference to what the code actually does
* They eat up a lot of project time and so projects tend to become late. As the documentation is what you have to write first by the time you get to the code you have much less time to actually write the dam code
* Extreme documentation actually reduces code quality. I've worked on many code bases where the code actually references page numbers and sections rather than what it actually doing. This is often the case with contractors that are only on project for a short amount of time and thus translate the docs directly into code. Also if there are and errors when creating these docs they are often translated into the code often into performance / non-functional problems
* Docs written after the fact end up being rather pointless / unusable as you'll have to describe all the weird things you done to make it work properly / fast ...etc
* Non technical people will read what you've written not understand it, because it's highly technical, misinterpret it then use that strange idea of things they've got all over the place. Like someone that doesn't know what a Foreign Key is but seen it once and sticks them on every column in the DB. Then you'll have to have a fight with them as "it says here on this doc"
I could go on but I suspect what I've written here is quite unpopular so I'll end by saying that documentation is very hard to write correctly you need specialists who know exactly how to describe what's been done in the system to others. You also need to balance the amount of docs you create vs the actual work on creating the thing.
Again on Project Management you described it as "Obviously there are inefficiencies with big companies" that sounds like you've never been in a full 8 hour days worth of meetings getting 0 coding done and just explaining to 10 different managers what needs to be done. Some of these big corporates are so colossally inefficient that people have been quitting on mass during the pandemic to get away from it. It's a serious problem not just to be swept under the rug like oh well that's just what big companies do. I heard someone either on reddit or on here defend a 3 hour long "daily standup" meeting because it was good to know what the devs are doing. Like yeah there are in you meeting for 1/2 of the day.
Now I don't condone 0 project management but companies seriously need to cut it back. Tools like Jira have made working hell for some programmers.
I think you missed the point about documentation and project management taking inordinate amount of time and manpower compared to the output in both quantity and quality.
It takes a bit more perspective to understand that no one can know it all or do it all. Contributors other than "coders" and implementors such as Product owner, scrum master, tester, manager play a key role in guiding the implementation. By the nature of those jobs, they are not as quantitatively measurable as an engineer's job.
Toward that end, I would recommend three old and poorly written books with timeless and wonderful ideas: The Goal, Critical Chain, and Managing Corporate Lifecycles.
While these books are all about management and running a company, I think they lend perspective to developers on why certain things happen the way they do. They can also help someone recognize and pick a healthy organization to work in. Just like books on software development, these books augment experience, they don't replace the need for it.
A project that I quite enjoyed involved months of investigation work, finally solved by tweaking a single software parameter that dictated how far a release mechanism moved. The number of internal/external meetings I had to demonstrate that this can indeed fix the problem could have seemed silly but it was also very reasonable given the risks involved.
There was a case here were an (employed) dentist was apparently bored and started to drill and fill perfectly healthy teeth. Iirc, criminal charges were filed.
Malpractice because bored (or feeling undervalued/underappreciated etc.) isn't just a problem for SWEs, but actual doctors. Also see: nurses and doctors inducing code blues to get to be the hero saving the patient; firemen becoming arsonists to have a fire to extinguish.
In dentistry? 1 of every ... ? 1,000 teeth? More? Less?
https://www.theguardian.com/society/2000/apr/16/futureofthen...
That's a great metaphor for code-before-you-know developers.
> finally solved by tweaking a single software parameter that dictated how far a release mechanism moved
I think of this type of work as programming by other means. The problem couldn't have been "fixed" without all the discovery meetings and understanding. The "fix" couldn't have made it to production without political agreement.
Is that computer code? No. Is it building a solution to interact with a complex system (of people), using the primitives available to you (less than VP-style "Just do it"), to realize a desired outcome? Yes.
Others may be different, but I find hacking obtuse process problems and corporate political structures just as fun and rewarding as a nice piece of code.
A key difference between a big decision and a small decision is what it's like to change your decision afterwards.
I don't think we can compare reverting a pulled tooth vs 2 hours of programming the "wrong" thing.
In the programming case, you may have went down a rabbit hole that wasn't correct but at least now you're 1 step closer to the right solution. You probably learned something and the business can write that off as R&D.
In the pulled tooth case, well, I'm not sure I want to Google that haha. Is it possible to fully replant a pulled tooth in a way where it's 100% healthy and you'd never notice it was pulled? I know there's implants but I mean the real natural tooth, complete with its root. I'm sure the process in any case would not be fun for the person who needs the work done.
You could classify one of these as a small decision and the other one as large.
I still think planning and understanding the problem before coding most things is a very good idea btw, but I would feel way more comfortable experimenting with code in short periods of time vs experimenting in a dental chair / operating room.
I don't want my teeth pulled just because. If it's a fix to a problem - a means to an end - and there's no other way to do it, I'll consider it. Likewise, I don't want to work with developers who are super passionate about typing code into vim. I want to work with developers who are passionate about solving problems. Code can be a means to that end, and by the time it gets to us we typically already know we need some code for it, but the danger is spending days or weeks writing code nobody needs and nobody asked for because it's "their passion."
If we write 10,000 LoC for something that we didn't end up needing... the team's going to be tempted to wrangle that into the actual purpose instead of throwing it out.
So overly aggressive fingers on keyboard lead to more bloated results, as requirements drift during development and more code is written to target them.
Some problems genuinely require a lot of this kind of deliberation, but most don’t. Some meetings aimed at this kind of deliberation make meaningful progress, but most don’t. The person who can terminate or pre-empt an inflated or stalled conversation with working code is extremely valuable.
Even if that code is not the ultimate solution, it has a definite shape and objective properties that can be investigated and weighed, which brings rigor to discussions that get lost in abstraction.
Organizational politics and entropy also tend to create too much talking: it is good for your career to present the work you’re doing as requiring a lot of collaboration (whether or not it does), it is easier to spitball in meetings than to actually solve problems (if you even have the skills), and you have to go to all the meetings you’re invited to (while coding time gets ruthlessly prioritized).
Exactly. Many times, the best code is no code. And making decisions about what code to write need meetings, unfortunately, or at the very least some kind of coordination.
Meetings are useful to clear up this stuff and at best result there is simpler solution, or not need to do work at all.
The author of the post, in my reading, laments petty meetings not productive ones.
In small orgs with a headcount of tens that's very easy for developers to grasp the value and the need for certain things.
But when you're in a 1000+ developer organization it is often the case that the reason you have to do something is because this is a requirement coming from two or three management levels above.
In some orgs, a lowly developer might even be unable to even sit at the table with the big boys. They might have a say and a good perspective in micro decisions, but not in macro ones. In this case, I can definitely see TFA being written.
To use the dentist example, imagine a dentist that's passionate about pulling teeth, but doesn't get a say on wether the teeth should be pulled or not.
imagine thinking this is bad, unironically.
You misquoted in order to leave out the fact that the documentation is 50 pages, and some of the tests are useless, and arguing with colleagues is not always productive.
also, you don't know which tests are and arent useless beforehand. code coverage may not be the perfect metric, but correctness is is semi-decidable anyway, so if one claims before hand that some coverage test is useless, he's most likely being lazy or drown in his self importance.
and arguing technical decision is always productive, so much that rubbe ducking is an actual methodology becuse even arguing alone is better than go head down with aggressive randomness.
I'm claiming they're not universally bad, and that the claim they're universally bad is absurd - if unsure about the interpretation, please do refer to the initial post - you might want to start applying that charitable interpretation thing.
Besides I've provided reasoning for the elision and that went completely unaddressed, probably because assigning some absolutism to the argument that wasn't there and dragging me to court on trumped charges seemed easier
That's called a strawman. Yeah, it's very easy to do and very convenient to knock out, and I hope you had fun doing so, but you didn't really address the author's real position here, as much as you insist that you just removed "figure of speech".
About the "dragging me to court on trumped charges" part, oh, the irony. That's exactly what YOU are doing. :)
If you're really asking for an arguments: the fact you had to edit the quote should be enough clue that the original statement wasn't as clear cut as you're portraying. The fact people disagreed with you (with downvotes or comments) should also point to that. Maybe take a second to consider that you were uncharitable to the author and they're not as stupid and as extremist as you're painting them.
Jesus who's doing the personal attacks here?
And, no: that’s not a personal attack, as I’m talking about your acts, not yourself.
Once again I’m up for any discussion, but that won’t matter as you ignore anything that can’t be used to make your interlocutor look stupid. You sir haven’t argued in good faith. You began this whole thing with a bad faith misquote, and when you couldn’t do it anymore you began to cry foul, while at the same time criticizing me for doing so. And that’s the only thing you’ve done so far: acting in bad faith.
really? beacuse it appears from the last six or so messages you're only interested in dissecting words, ignoring whatever meaning is therein contained, and you're only available to debate the single topic that you picked, which today appears to be wether making summaries is allowed or not while presenting an argument, and are prepared to just diss and dismiss anything unless it falls exactly in your extremely narrow debate window.
I worked in the past at a company where Softbank asked for the dev headcount to be increased as a condition of the funding. Lots of teams ended up being responsible for halves of pages, half of a microservice, etc.
To me this post has junior dev perspective but also the coworker I had the conversation with is in his 40s and I’m starting to think there is some generational thing going on here
Sure. People always over-estimate their abilities, and under-estimate problem complexity. It's easy to say something like the above when you're already looking at the solution.
This isn't even necessarily inefficient, because productively doing work that isn't needed isn't helping anyone either.
We had this "important project" coming up, a certain big feature that was wanted in the platform. A project which would take about 6-9 months with the collaboration of various teams across the company.
I was involved but only in a helping role. One member of my team was involved but they were fairly inexperienced and so I was asked to go in as support.
After the first two meetings a number of things became clear. Mainly that the product owner for the project was extremely ambitious, clearly not knowledgeable about the technology involved and got very upset about any concerns or problems anyone would point out. They wanted "those stupid meetings" to be just for informing them of solutions and progress, not for discussing problems and options.
At the third meeting I made the mistake of mentioning that a particular detail, not too important, would be extremely costly to do as asked and that we would be better off doing it in a much simpler form. Unbeknown to me, that day the product owner went behind my back and asked for me to be immediately removed from the project. So I was. I didn't care much for it and I only learnt about that move much later, when I had already left the company.
Anyway, the project ended up taking about 2 to 2 and 1/2 years and it had to really reduce its scope in the end. And some of the people involved confessed that it was because of the product owner, because they had wanted people to "just build this thing I say and stop arguing". A lot of work was simply thrown away several times simply because of not having had the proper discussions it needed.
Doesn't mean the job role is useless.
I've been a full time software engineer (now lead) for the last 9 years. I've been in similar situations to this article where most of my time was spent in useless meetings that I disliked, I tried to improve things, to focus meetings, to improve our efficiency.
And all that aside I still love coding. Granted not all types of code, not the one I have to write sometimes at work.
Just now I'm starting another little fun side project that I've been coding on my free time these last few weeks.
All this is to say that coding is just a little tool, what you build with the tool is what can be fun. I think it can be healthy to write code that does fun things from time to time, even if the code you write at work is for the most boring aim.
This is mainly because most other people can execute with a better level of completeness than I can in the context of open source dev. This is mainly because I don't actually like programming, but I sure as shit love the niche I am programming for...
Linus doesn’t write any code, in his own words, but that’s in part because his knowledge of software makes him better at leading people than writing code now. But Linus is not all leaders of the industry, many of them still do write code. John Carmack still writes code. That said, why should high profile programmers continue to code? What exactly does it say if they move into management?
Nothing wrong with viewing work solely as your means for funding the important parts of your life.
Complete opposite to when I was a bright and hopeful fresh graduate
I assumed you were being sarcastic, but re-reading your post and looking at the replies, I guess you're being serious here - I do actually like writing software. I'm not pretending or fooling myself - besides playing music and raising vegetables it's one of the few SFW activities I actually enjoy. I tolerate meetings because they're part of the price to get to write software and actually get paid to do it. What I don't enjoy are the unreasonable expectations around how long things ought to take or how predictable software development ought to be.
I think the assumption that these people want to program for more than 2 hours per day is probably wrong, and you will just burn yourself out trying to do 8 hours of programming every day. In fact, many of these people burnt out long ago and just try to find anything other than programming to do.
I wonder though, it is true that these companies are very inefficient, yet they never get taken over or superseded. Why can't the group of rogue programmers that are more productive take over any of these companies?
vs
low physical activity, where often the work requires multiple people manipulating highly abstract concepts with purely imaginary connections (I write the API, you write the caller).
I.e. assembly line worker vs carpenter
I'd hazard most people tend to dislike repetitive work, if they have the choice.
Although I guess even the most repetitive physical task still has infinite physical fidelity, if you look for it. E.g. digging a hole in the same place 50 times vs writing the same code 50 times.
Take a "self driving car". Except... you can't really crawl into the back seat and eat lunch. No. Are you kidding me? You have to pay attention! You have to be ready to grab the wheel! A walrus could be napping on the freeway! Just because it's self driving doesn't mean you don't have to pay attention! Good god, what's wrong with you?
What's wrong with us, collectively, is we don't immediately recognize the absurdity of what they're saying. There's really something very very wrong with that person.
They even made a movie with that premise (Office Space).
1. For whatever external or internal reason, they fail at writing good software for a long time
2. The job takes a terrible physical toll (lack of exercise)
Neither of these are improved by larping at corporate business stuff around the office.
Maybe line cooks at slow restaurants have fun getting high and chatting while they cook, but many many jobs are physically painful, intensive and low-rest, and/or high stress and bad hours service work.
Management could many times done better of course, managers are as lazy or incompetent as other people, if not more.
Yes big companies have productivity issues, however they have to create software which will outlive most engineers working at the business. You cannot reach the SLOs of google by hacking something together in 2 months!
"Everything we've looked at so far is a technical problem. Compared to organizational problems, technical problems are straightforward. Distributed systems are considered hard because real systems might drop something like 0.1% of messages, corrupt an even smaller percentage of messages, and see latencies in the microsecond to millisecond range. When I talk to higher-ups and compare what they think they're saying to what my coworkers think they're saying, I find that the rate of lost messages is well over 50%, every message gets corrupted, and latency can be months or years"
Dan goes on to say: "When people imagine how long it should take to build something, they're often imagining a team that works perfectly and spends 100% of its time coding. But that's impossible to scale up. The question isn't whether or not there will inefficiencies, but how much inefficiency. A company that could eliminate organizational inefficiency would be a larger innovation than any tech startup, ever."
Communication scales extremely poorly compared to code and large organizations require a very different skillset than small companies. The author seems like someone who just loves writing code as opposed to wanting to deliver maximum business value (As defined by the company), so it makes sense he dislikes big companies.
There are also good and bad big and small companies. A well run big company is still going to have a large amount of communication overhead vs a small company.
We're not all a bunch of mini CEOs.
Maybe he worked at poorly managed companies, who knows. The fact that he was asked to participate in meetings instead of only being assigned purely code-related tasks isn’t very compelling evidence of a company being a “joke”.
I dont think that relatively speaking companies that dont do this are horribly run since it seems to be the norm but I can see why somebody who isnt used to it would rant.
In general larger companies do everything inefficiently. It's to be expected. Small companies wouldnt exist otherwise.
The author's complaint was that he only gets to spend 12-25% of his time on these tasks on a good day.
When you read about organizations which were highly effective there is usually a common theme of management by objective and giving people ownership. “The HP Way” and this speech by Rickhover are two such examples: https://govleaders.org/rickover.htm
I think the point is that very little actual business value is being created. This not necessarily due to "actual business needs" but because of deterioration of culture over time and the inevitable principal-agent induced issue of managerial bloat.
Instead of accepting that increased communication needs will slow down everything to a crawl, how about eliminating needless communication? Thats how Amazon does it, and look where they are now.
Whenever the "we hate meetings / the current bureaucracy" crowd criticizes the current state of affairs, the opposition tends to seek the high ground and go "well but you just don't understand what drives value". Meanwhile, there is a surprising lack of numbers regarding all this.
But I'll also say a positive word for qualitative reasoning based on experience being a good first approximation of things. If something gets pushback from a lot of people who have spent a lot of time trying to coordinate large efforts, then it's worth considering that those people may be right. I don't know anyone who has spent a lot of time in one of these coordinating roles who thinks that the primary issue is too many meetings and not enough code being written.
It's one thing to consider it an approximation, it's another thing entirely to consider them "right" which is frequently followed with "so we won't investigate any further". Most of us don't live in situations where such decisions are actually critical. We can afford to criticize and experiment. Instead, this line of reasoning tends to be misused and shush any investigation.
>I don't know anyone who has spent a lot of time in one of these coordinating roles who thinks that the primary issue is too many meetings and not enough code being written.
And you don't think that group, much like others, may be a little self-reinforcing?
I don't think "that group" is self-reinforcing at all. Essentially everyone who comes in with no experience comes in thinking "meetings are crap, communication is crap, we just need to write code". Most of those people (but not all!) slowly but surely change their minds as they gain experience. But every one of those people is an opportunity for the thesis to be disproven. Similarly, nearly every new organization is an opportunity to try something new. Google didn't start out with lots of meetings and engineering committees and design review processes. They started out just wanting to write tons of code. They didn't hire management (or "agile") consultants or bring in outside managers as they grew to come tell them how to behave like a big company is supposed to. The people who started out writing all that code and ridiculing bureaucracy are the same people who eventually accrued processes to manage meteoric growth.
I really don't think people are as narrow-minded and closed off to this as you seem to believe. People are hungry for a better way to manage organization growth, it's just a high bar because people have seen lots of these kinds of efforts, and frankly just get kind of bored of chasing "one weird trick to make everyone way more productive" again and again.
If that's common and not being addressed, it must not be important. If it's not important, why mention it? Seems like victim-blaming.
It’s easy to understand why. The 15 minutes spent bickering over the color of a button will be far more likely to leave an impression and remembered vs the 90 mins spent on ordinary, necessary and useful discussions in the same meeting.
I'm sure it varies for people (which is why you're downplaying it), but for at least some of us, it is simply the truth, the reality we have to face every day we go to work.
I've also worked in consulting and appreciate the explicit requirements, but I find the formality much less efficient than the process you describe earlier. It ends up being very "waterfall" and exactly the approach the Agile Manifesto attempts to counter.
Perhaps you prefer a more waterfall, hierarchical development process, or the companies (big ones) or industries (highly regulated) that necessitate it?
A week-10 day sprint on _one feature_? They haven't drunk the scrum kool-aid yet. Just wait until they do - then every feature will be a "story", and no individual story will be allowed to be assigned more than 8 "story points" (which for some reason means "one day"). If you think a "story" will take more than 8 "story points", you'll be asked to break it down into "subtasks" of no more than 8 "story points" each (you'll be asked to do this accurately in a few minutes in a standup meeting). Trust me, if you tell a higher-up non-programmer that there's anything wrong with the development model, they'll hear "we need to move to the 'scrum' everything-is-mandated-to-take-less-than-a-day development model".
What he mentions about big financial companies (where software are for internal workflows) that is the life, and there are many of them and they are usually big employers.
And what he says "You see, we were always busy but seldom productive" is actually the essence of 'Mythical Man Month'.
About FAANG/MAANG, I have seen brilliant college toppers mucking around with html tags (but not able to get them right).
High salaries to a lot of software worker is a joke indeed.
At the start the founder group are rutheless productivity-chasers. Then the corp expands to include the its-just-a-job group. Everything ticks along well, and at some point, the rutheless can't manage the group. So they hire followers to listen to their orders and thereby manage others. In this sense middle management is really "corporate following".
Now you have the its-just-ajobs, rutheless-productives, rutheless-leaders, and leader-followers.
When the corp grows too far the balance in these populations is thrown way off (by, often, the shortsightedness of the real leadership in balloning middle-management to cover for them).
At this point all the meaningful decisions are still held by the exec, but middle management are now so large they have to "find something useful to do", which is regulate all the meaningless decisions.
At this point most of the ruthelessly-productive leave, and you're left with the justajobs, leader-followers and the few clueless productives who'll destroy their mental health trying to grapple with it all.
The gervais-style analysis mystifies some of the issues it describes. The heart of the group dynamics is "leader vs follower", "rutheless vs clueless" and "transactional vs passionate".
A startup is largely "passionate rutheless leaders", it grows to include "transactional ruthless followers" (its-just-ajob), then to "passionate clueless followers" (middle-management). At this phase its highly stable... you hire in "passionate rutheless followers" (ie., more actual workers)... who also need more middle-management... and at somepoint this becomes unbalanced due to poor executive incentives.
That gives you your large population of "passionate clueless followers" (ie., middle-management), and the death of the productive phase of corp. action, into a more rent-seeking (or death) phase.
In gervais, "losers become sociopaths" in a mystifying way; and likewise the "clueless" population is inexplicably unpromotable. My breakdown, for example, clarifies why: the "clueless" population never become rutheless-leadrs as they arent leaders at all. They're followers.
I think muddling "transactional" dispositions with "rutheless" ones also mystifies the issue, under gervais, the "noble sociopath" is hard to explain. Really, its that they're both passionate (internally motivated) and rutheless.
---
NB., rough definitions: "leader vs follower" (I command vs. I am commanded), "rutheless vs clueless" (success requires it vs. virtue requires it) and "transactional vs passionate" (external-reward vs. intrinstic-reward).
I suspect if one were to compare a large number of startups to one large company (or even better a portfolio of large companies), the “ruthless founders” will significantly underperform the middle management in large companies even after adjusting for the inherent advantages large companies have.
The only reason the “ruthless founders” look better is because we usually only talk about the successful ones because unsuccessful ones have disappeared.
Middle management is more successful and ruthless founders are less successful than immediate appearances would suggest.
a business needs an executive, and at scale, it needs middle management to implement the general strategic direction set by the executive
if there are more middle-managers than this requires, they start trying to own non-strategic issues -- which is where you get large numbers of meetings about non-issues
Ah. Damn. Thanks for the reminder.
0 - https://www.stilldrinking.org/programming-sucks
Oof, sounds like the author is the joke.
I've spent more time on tooling for myself than i got out of it in saved time and learned a ton without pay. Alternatively i'd have been paying a match of a videogame that i'd have forgotten about by and probably regretted now.
These past days I spent a lot of time doing research into and designing an own keyboard at home. Something similar exists but is imo overpriced yet i'm not even saving money given all i've spent on a soldering iron, etc But i'm enjoying myself just creating something that i've gotten invested in.
Meanwhile at work I feel like a damn clerk. Making minor changes, arguing, pushing little bits of overhead out of the way and working slowly on something i consider an inherently inefficient design bound to require a complete rewrite at some point for reasons out of our control.
I wish i could go back to those occasional few problems I cared about to work just that bit more to get it working. In neither scenario I really cared about the overarching company but if there was never ever anything to catch my drive like that i'd have changed jobs by now.
The work will still be there for him the next day, there's no need to work overtime on it.
Okay, but doesn't everybody know that already?
Having been programming for 30 years I find most of it pretty funny.