Many software companies are a joke

https://liou28335.medium.com/many-software-companies-are-a-joke-9f4b10378c7a

by openplatypus • 4 years ago

451 368 4 years ago

liou28335.medium.com

Juliate4• 4 years ago

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".

Juliate4• 4 years ago

That also explains the "design by committee" thing and the ugly/desperate UX some corporate apps have.

regularfry2• 4 years ago

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.

emteycz• 4 years ago

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.

WJW• 4 years ago

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.

Juliate4• 4 years ago

"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.

jokethrowaway2• 4 years ago

I disagree.

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.

Juliate4• 4 years ago

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).

It's "a bit" similar to the 40% lazy ants thing (https://boingboing.net/2017/09/12/living-larders.html).

sam_lowry_• 4 years ago

Here are a few personally lived counter-examples:

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.

Negitivefrags2• 4 years ago

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.

bigDinosaur2• 4 years ago

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.

Negitivefrags2• 4 years ago

Oh I’m sure that it feels like they are doing something.

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.

baybal2• 4 years ago

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.

mesozoic• 4 years ago

But I'm encouraged to take a project it would take me a day or two to do and give it to a junior engineer to take weeks on it so they learn.

fy20• 4 years ago

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...

akvadrako• 4 years ago

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.

Jensson5• 4 years ago

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.

cmrdporcupine2• 4 years ago

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)

https://goomics.net/364/

mike109212• 4 years ago

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.

commandlinefan5• 4 years ago

a job where I felt like I had it easy

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.

EdwardDiego• 4 years ago

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?

It's a very different kettle of fish.

pc862• 4 years ago

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.

_fizz_buzz_• 4 years ago

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.

ZephyrBlu4• 4 years ago

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.

ejb9992• 4 years ago

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.

ketchupdebugger• 4 years ago

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.

reallscoliosoi3• 4 years ago

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.

ethbr017• 4 years ago

Free market capitalism is the least efficient allocator of work and pay, except for all the others.

pyb• 4 years ago

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.

lupire5• 4 years ago

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.

ratww13• 4 years ago

Yep.

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.

BeFlatXIII4• 4 years ago

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.

knotofvipers2• 4 years ago

I am not sure it is even that rational though.

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.

bo1024• 4 years ago

to do nothing

The author puts it better: they do lots of things, all day long, but produce almost nothing.

cmrdporcupine2• 4 years ago

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.

mike109212• 4 years ago

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..

commandlinefan5• 4 years ago

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.

batiudrami2• 4 years ago

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.

jokethrowaway2• 4 years ago

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.

batiudrami2• 4 years ago

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.

mschuster913• 4 years ago

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.

remus• 4 years ago

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.

blowski5• 4 years ago

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?

shortformblog2• 4 years ago

This guy also wrote a hater’s take on open-source a few months back: https://liou28335.medium.com/why-i-dislike-open-source-acbc2...

Something tells me he’s gunning for that Medium paycheck.

op00to• 4 years ago

Oh man, that open source article is hilarious! Thank you for sharing.

politelemon• 4 years ago

Medium paycheck.

I'm sorry, what? Out of the loop here.

mschuster913• 4 years ago

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?

ano88888• 4 years ago

Yep. I think the author fails to understand that coding is only a small part of the process of writing production software.

rxhernandez• 4 years ago

Do you think that sw engineers at startups aren't largely writing code for most of their job?

sdevonoes• 4 years ago

But there are different roles that come into play when it comes to writing production software:

- 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).

dgb23• 4 years ago

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.

sshine2• 4 years ago

complaining about needing to do documentation

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.

mytailorisrich3• 4 years ago

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.

onion2k4• 4 years ago

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.

oneeyedpigeon3• 4 years ago

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.

jp0d• 4 years ago

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.

scotty79• 4 years ago

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.

mrcartmeneses2• 4 years ago

“ 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.

gitfan862• 4 years ago

"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.

ethbr017• 4 years ago

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.

amitport5• 4 years ago

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.

paganel• 4 years ago

Excellent comment, just wanted to add to this:

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.

21432• 4 years ago

[Tangent]

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!

rob_c4• 4 years ago

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.

danielvaughn• 4 years ago

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.

bayindirh2• 4 years ago

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.

urthor2• 4 years ago

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.

Jensson5• 4 years ago

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.

xpe12• 4 years ago

Author is every software engineer I hate to work with.

Wow. This looks like a quick and harsh over-generalization. This sounds like a pretty deep-seated lack of understanding.

xpe12• 4 years ago

Not recognizing that after 20 years in the industry is baffling.

Baffing, cognitively?

Or is this a value judgment?

Have you observed human nature particularly in the last ten years w.r.t. echo chambers?

Cthulhu_• 4 years ago

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.

vsareto• 4 years ago

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.

jseban• 4 years ago

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.

lelanthran• 4 years ago

"Delivering a product that solves end user needs and is as maintainable and reliable as possible" is the only truly important thing

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.

Simon_O_Rourke• 4 years ago

The writing is smug and shows no self awareness

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.

mschuster913• 4 years ago

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.

mkl95• 4 years ago

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.

andersonmvd• 4 years ago

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.

rob_c4• 4 years ago

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.

ljm2• 4 years ago

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.

turing_complete• 4 years ago

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.

xpe12• 4 years ago

It is easy to confuse "so little perspective" with "a different set of values". This seems to be the case with ^.

xpe12• 4 years ago

^ wrote:

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.

Dave3of5• 4 years ago

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.

WesolyKubeczek• 4 years ago

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.

ineedasername2• 4 years ago

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.

reacharavindh• 4 years ago

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.

caseymarquis• 4 years ago

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.

osigurdson• 4 years ago

3 years, 20 people, 24K LOC does sound objectively inefficient to me for the project as described.

a_square_peg• 4 years ago

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.

formerly_proven• 4 years ago

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.

xpe12• 4 years ago

What are some estimates for the likelihood of these behaviors?

In dentistry? 1 of every ... ? 1,000 teeth? More? Less?

ethbr017• 4 years ago

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.

nickjj• 4 years ago

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.

bambax• 4 years ago

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.

Ekaros• 4 years ago

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.

avereveard7• 4 years ago

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.

imagine thinking this is bad, unironically.

ratww13• 4 years ago

This is not what the article says, however.

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.

avereveard7• 4 years ago

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.

oxff• 4 years ago

I think the inflation / funny money being injected doesn't help at reducing fake working.

ratww13• 4 years ago

It definitely doesn't.

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.

Lapsa• 4 years ago

my favorite - forcing signing "Code of conduct" that pretty much says you gonna try to be a good person (as if you were not beforehand)

867-5309• 4 years ago

"Tame in me the tempers four, that I may serve thee evermore. Place in me the values nine, that I may feel thy touch divine."

williamkuszmaul• 4 years ago

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.

lnxg33k1• 4 years ago

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

secondcoming• 4 years ago

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.

amelius• 4 years ago

It's a sad thing that there is so little money in making scientific software; better make some dumb flashy app if you want to retire early.

bayesian_horse2• 4 years ago

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.

genezeta2• 4 years ago

One place I worked at some years ago...

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.

lupire5• 4 years ago

Yes, some product managers or whatever are terrible at there jobs, just as some programmers/engineers are.

Doesn't mean the job role is useless.

throwaway65323• 4 years ago

Comments like this are why I find reading HN to be both depressing and cathartic at the same time. That's quite an achievement.

lurker5312• 4 years ago

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

reallscoliosoi3• 4 years ago

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.

aurbano• 4 years ago

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.

Der_Einzige• 4 years ago

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...

dahart3• 4 years ago

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?

BeFlatXIII4• 4 years ago

As a worker, I like your attitude. As a manager, my attitude toward your attitude is entirely dependent on your competence.

Nothing wrong with viewing work solely as your means for funding the important parts of your life.

lurker5312• 4 years ago

I’ve been employed at my current company for 6 years now, I do what needs to be done but my feelings are stated above.

Complete opposite to when I was a bright and hopeful fresh graduate

commandlinefan5• 4 years ago

imagine actually liking to write software

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.

reallscoliosoi3• 4 years ago

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?

mellavora• 4 years ago

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),

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).

ethbr017• 4 years ago

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.

mytailorisrich3• 4 years ago

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).

throwaway235203• 4 years ago

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.

lupire5• 4 years ago

People burn out on programming for two reasons:

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.

yunwal• 4 years ago

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.

mihaaly• 4 years ago

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.

gray_50• 4 years ago

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.

agounaris• 4 years ago

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!

ZephyrBlu4• 4 years ago

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.

snarf21• 4 years ago

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.

pydry2• 4 years ago

It's kind of trite to say that though. It's the business's job to ensure that the skills and resources at its disposal are put to good use, not yours.

We're not all a bunch of mini CEOs.

MrBuddyCasino2• 4 years ago

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.

sanderjd4• 4 years ago

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).

ZephyrBlu4• 4 years ago

"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.

gone35• 4 years ago

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.

thawaya31133• 4 years ago

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.

Beltiras3• 4 years ago

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.

claytonjy2• 4 years ago

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?

commandlinefan5• 4 years ago

a week-10 day sprint

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".

deterministic2• 4 years ago

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.

AndyMcConachie• 4 years ago

Is there anything new ever written in this space or is everyone just repeating what Fred Brooks said in the 1970s?

hazmazlaz• 4 years ago

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.

achow• 4 years ago

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.

zcbenz• 4 years ago

I feel really sorry for the author, what he said does not deserve such mean comments.

mjburgess3• 4 years ago

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.

milkshakes• 4 years ago

this is the gervais principle

mjburgess3• 4 years ago

Same phenomenon, slightly different analysis.

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).

thawaya31133• 4 years ago

I suspect a lot of this is survivorship bias.

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.

mjburgess3• 4 years ago

sure, it's about ratios

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

throwaway65323• 4 years ago

Perfectly describes my last job.

d232• 4 years ago

the few clueless productives who'll destroy their mental health trying to grapple with it all

Ah. Damn. Thanks for the reminder.

mbrodersen• 4 years ago

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.

gherkinnn• 4 years ago

I get the frustration, but this reads like Programming Sucks [0] without the wit.

0 - https://www.stilldrinking.org/programming-sucks

dairylee2• 4 years ago

I remember we would choose to work overtime due our addiction to the problem we were solving

Oof, sounds like the author is the joke.

modo_mario• 4 years ago

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.

dairylee2• 4 years ago

Why? From his description it sounds like he enjoyed it and that's probably the best kind of work.

The work will still be there for him the next day, there's no need to work overtime on it.

praptak• 4 years ago

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.

Okay, but doesn't everybody know that already?

t43562• 4 years ago

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.

gandutraveler• 4 years ago

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.

xtracto• 4 years ago

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.

rob_c4• 4 years ago

Dear author, you're one of those people who are capable of more and need to take an unfortunate step back.

Given there are so many people who flocked and are still flocking to IT based programming jobs because of the promise that "one day you will be the next <insert-billionaire-here>" level push.

I've met people who burn themselves out trying to write hundreds of lines of good code in a day. I've had new colleagues come in, publically slate my code, only to have to retract their comments in private several months later once they actually understood what it's doing.

The author is probably one of the types, that left as seniour architect could have build something better with people around him adding polish and other "perceived value" to a customer. (Perceived value in this case being everything from corporate branding to translations to internal tooling).

Most "complex" problems from the non-IT world don't need a full stack all singing all dancing latest npm, all the RAM in the world and a full Oracle site lisence. Most could be solved by some talented coders (3 or 4 max) doing the grunt of the work with others around them adding perceived value to allow the company to add a zero to the net value of the product, and it could be deployed in-house on a 2nd hand server with redundancy built for <$30k for it's whole lifetime. And that's assuming it's not just an app to sell that requires no hosting.

jleyank• 4 years ago

These were not “software companies”. Such companies sell software. These were “normal” companies dabbling about automating processes and “being modern”. If software isn’t what keeps the lights on, it’s just a playground or a cost centre.

zmmmmm• 4 years ago

Another take on it is that in a big company, even incredibly mundane and boring software can scale to a level that is stupendously valuable once it goes into production. Hence the company can completely afford to have an entire team working away writing 3 lines of useful code a day. It is way more important that the code is created in a way that can mesh with the rest of the giant corporate behemoth (so yeah, documentation, meetings, etc etc) than it is that it is done fast.

albertTJames• 4 years ago

The guy made "only ennemies" in big companies. Not sure he'd be the most unbiased person to comment on the quality of tech jobs or somebody who can comment on healthy coworker relations.

When the same pattern keeps happening to you wherever you work, its not them, its you. That you had a few good positions in healthy teams does not make you a healthy coworker, the culture was probably just too strong and healthy for you to mess it up.

da39a3ee• 4 years ago

You have to learn to say no to pointless meetings. It's true that there are many stupid people who will try to hold them and they have to be corrected. Usually saying "I won't contribute anything valuable and nor will I gain anything valuable, so it's not the right use of company resources" will suffice. This means that you have to develop your skills so that you are not scared of acting like that (not scared of being fired). It's ok to be fired / leave a company -- the goal is to not be scared that you can't get a better job if they fire you for pushing back about meetings.

Joel_Mckay6• 4 years ago

Sometimes entrepreneurs start a company as a joke hobby while working in a coding pressure-cooker. Then a decade later end up growing up with clients in a completely different sales field. For sure, it is easier to complain, than to take responsibility. =)

mattwilsonn888• 4 years ago

What is this mythical concept "Business Value" which floats around undefined, unquestioned, in the impassioned rebuttals to this post?

If I can hire one person instead of ten to finish software in one third the time, even if it needs significant tweaking by the end, is that not "valuable" to my business? Please define and expand your terms.

drdrek2• 4 years ago

His Dilbert level insights about corporate life are very old... running a business is complex and gets less efficient with size, that is no great wisdom.

Building a code project with one person is great but consider the following issues: 1) Making sure the software is built to specifications 2) What happens if he leaves? 3) What happens if another urgent project arrives 4) Who will do support? 5) Who writes documentation 6) What about integrations with other systems in the business 7) What about IT/DevOps and server maintenance? 8) What about communicating it to other people in the org? I'm sure we can find more.

The generic use of term "Business Value" in this instance means that while development time is indeed a measure of efficiency it is only a small part the overall value that a company needs in a project.

Just to make sure I'll state again, large corporations are indeed not very efficient, I do not argue that, but they are profitable.

dahart3• 4 years ago

Business value is defined by the business in question, and what’s valuable to one business isn’t valuable to all businesses. The point is that the goal is a collective goal and not an individual goal.

If you really can hire fewer people to get the job done, and the value you care about is lowering the costs of employing people, that certainly is valuable, and you should do it.

Business Value is a term you learn to understand very quickly and deeply when you start a business and hire some opinionated programmers who complain loudly about having to talk to others and document what they work on, and proceed to have trouble meeting their deadlines, or create issues that others need to help fix.

I’ve personally watched what happens with programmers who write code without talking to people enough, both individual programmers who seems prolific, and groups of programmers working on different parts of a larger system. When programmers refuse to stay involved in the discussion of what do to, they sometimes invent or imagine their own requirements, and they build things that don’t fit into what the business actually needs. This can be a colossal waste of time and money, even though all programmers involved were happy and felt like things were “efficient”.

The problem with the article is that the author is arguing for personal efficiency, at the expense of group efficiency. It’s funny to write something about software companies being a joke and then argue that it’s annoying to work with other people. The software companies that are a joke are the ones no longer in business.

drdrek2• 4 years ago

Companies are a business and not academic or artistic institutes... while developer wellbeing can contribute its not a goal on its own.

If those 20 employees work on a bullshit project that could be done in a month, but at the end of the day generates tons of revenue its a good business endeavor. Could it be done more efficiently? Sure. Is it a better business venture than a work of art C++ code that was done super quickly but made no profit? Also yes.

He has some good points hidden in there but his developer centric view is so 90's I wonder if he was wearing a jeans jacket writing this.

ChrisMarshallNY• 4 years ago

They are correct.

It doesn't matter, and nothing will change in large corporations. That's not a bad thing, or a good thing.

It's just the way things are.

I spent most of my career in large corporations; many of those years, as a manager, where it was my job to maintain all that overhead the author complains about. I'm quite aware of the need for it, and a good part of my job, was trying to streamline the overhead, and shield my coders from it, so they could get more coding done.

Nowadays, I work on my own (mostly), and the difference in productivity is amazing.

I remember when I first read The Agile Manifesto, I was, like, "These guys really get it!" It was a dawn of a new era. The scales fell from my eyes. There was hope! There was a light at the end of the tunnel!

The headlamp of the 5:15 Express, out of Sheboygan.

Seeing how "Agile" is being implemented in corporate (and also small corporate wannabe) shops kinda took the wind out of my sails.

But large corporations seem to get done what they need getting done. Very often, it's fairly "klunky" stuff.

But that gives small shops an "in." If they can speak to the customers of these corporations, they could make some sales.

Then...it comes time to scale.

Let the meetings begin...

ejb9992• 4 years ago

>Seeing how "Agile" is being implemented in corporate

Dictionary definition of agile: "able to move quickly and easily."

There is nothing 'agile' about how 'Agile' is being done in most/many big corps - yet another buzzword sold by high priced consultants who like buzzwords, to top-level execs that think they know what they want.

knotofvipers2• 4 years ago

One large corp I worked at, agile was really just an excuse to use minimum viable products in production.

We were agile until this shitty software was in production and then we would move on to the next project.

That was literally what we were calling having a startup mindset.

bumpyliquor• 4 years ago

> we were always busy but seldom productive

that. My experience as well. Not on FAANGs but on quite a few multinationals.

> You will argue with your colleagues and supervisor on every decision you make

and that. Politics are through the roof and driving out the good productive engineers. The people that have little to offer on the tech side though thrive in this environment creating a vicious toxic cycle.

mmcgaha• 4 years ago

This is why a lot of programmers work after 5:00 PM. You can get more done between five and nine than you can get done all day.

ineedasername2• 4 years ago

if we should display certain data using a particular chart

Why are software devs bothering with that to begin with? It seems like it should be something the user decides, even if they say something like, "I want a sparkline chart but make it real big and applied to all the data". And then I silently think to myself "oh so you want a regular chart but you heard the word sparkline once but don't know what it means. Okay, will do."

edit: to be honest my users are reasonable and that sort of example is rare.

varjag2• 4 years ago

There's one competent programmer for every 4.2 big thinkers, visionaries and non coding architects, so this is a natural order of things.

spamizbad• 4 years ago

I remember while I was working for a big financial firm as a software developer. I kept asking myself why we were doing very little coding. Most of my time was spent attending useless meetings, preparing boring slides, making goofy excel sheets and Gantt-charts and maybe 1–2 hours of coding a day if I was even lucky. The software that I and my team worked on was a basically a javascript web application that monitored and collected details about financial transactions in the company. Believe me when I tell you that I could have worked on the entire software myself in 5 months. The entire solution could not have been more than 24,000 lines of code (including lots of generated code). My team spent nearly 3 years building this software, most of the time spent in meetings, bickering over the pettiest feature like, if we should display certain data using a particular chart and what colour the chart should be.

Theoretically a Product Manager solves this problem for you: they are given the authority to be decisive about the details of a project, its scope, and they sit through all the boring meetings and manage the status update bureaucracy while working with the developers to actually build something.

miav2• 4 years ago

As the top comment points out, the author comes off as arrogant and their view is unbalanced, but they do have a point.

I find the saying "What a programmer can do in a month, two programmers can do in two months" is quite true. I consider myself competent and the people I work with are even more so, but human communication is always very imprecise and slow. If you stack it into a hierarchy of teams and managers, efficiency loss becomes exponential.

I really do think that the best way to organize software development is to have discrete components with exactly one person in charge of a component. Of course there are notable downsides. If only one person is in charge of a component it would become quite opinionated and it would be difficult for devs to spot each other's errors, but I think it would be a great tradeoff nonetheless.

I really don't want to spend even 5 minutes of my life debating whether we should split a folder into 2 smaller folders or not. I'd much rather have any member of the team go with their gut on this. An individual's choice may not be as good as that of the entire group, but it's good enough.

rrdharan• 4 years ago

This approach involves a high degree of risk, i.e. your bus factor is 1: https://en.m.wikipedia.org/wiki/Bus_factor

miav2• 4 years ago

Yes, absolutely. Having a single person do what they want with a component involves risks but I think they can be managed.

Say the dev in charge of an important component of a service is struck by a bus and dies. The optimistic scenario is that the code was well enough written that people developing adjacent components (ie. components that interface with that of the deceased dev) can effectively take over development in the short term until a new owner is found.

A more interesting scenario is that in which the dev abused autonomy and the component is utter spaghetti. In all but the most extreme of cases, the component could be kept in maintenance mode as is for some time. This would block progress that relies on changes in the component, but allow the service to continue working. In that time, other devs could either untangle the spaghetti and refactor the code into something workable or rewrite it. In both cases a significant amount of resources would be spent, but this is a scenario that's unlikely to occur often and the fact that the component was owned by a single person places a soft cap on the size of the component (and ideally an employee would maintain a couple of unrelated components to ensure they can continue working if one service is deprecated) ensuring it could be replaced within reasonable time.

thenerdhead• 4 years ago

Here's something I learned.

Yes working in big tech or a big company can have its fair share of red tape.

You can either accept this and work as a cog in the system, or you can start to poke the sleeping bear.

When you're overburdened with more meetings than time to do the work you talk about in those meetings, that's really on you, not the group of humans we call a company.

If your boss starts to attach your performance towards meetings, then maybe its time for you to have that conversation about how nothing is getting done and that by not accepting meetings is how you do get stuff done. It's all about balance at the end of the day. Most people are reasonable and will listen.

So while big companies may never change in practice, you can change how you work in a big company and see tremendous results by just saying "No" every so often. Most of the time nobody notices or cares, and when they do they respect you for protecting your time to do meaningful work.

100011_100001• 4 years ago

I 100% agree. It's about creating your own oasis. There will be friction from everyone around you, the only way to overcome it is by producing results and being very clear about your intentions.

Also don't be surprised if your manager / co-workers around you forget agreements that have been made. Occasionally you might have to compromise, other times stand your ground.

Moreover there is a fine line between poking the sleeping bear and acting like a prima-donna because things are beneath you. You can't always work on the most complex, or interesting projects. Someone has to fix the defects, produce the blue widget, now that the red widget is working.

Personally I try to alternate between working on "cool" things and a boring but relatively important thing. That way I support the team, but also make 10x progress on some things.

Meeting wise, I block out 4 hours a day (if I can) in my calendar. If you are using Microsoft Outlook you can setup Focus time. There are days that I do end up going to meetings during my focus blocks, but I consider it a choice.

Of course I have had multiple honest discussions with my manager to manage expectations on both sides. Figuring out your manager's main needs / goals can help a lot in those discussions.

j_barbossa• 4 years ago

Believe me when I tell you that I could have worked on the entire software myself in 5 months.

I find this way of thinking very short-sighted. It may be true that this application can be written in net time in 5 months, but much more important than writing code is to know clearly what is needed, what users need. Moreover, requirements and wishes change over time. I have seen more than once that months of development time were wasted on something the users didn't need, so good product managers and senior software engineers who question things are often more valuable than engineers who write hundreds of lines of code a day.

JeremyNT• 4 years ago

I think the problem here is that the company has software engineers sitting "idle" without any good requirements.

I don't think it's uncommon at all. The "hard" part of almost every project I work on isn't the ultimately the code, it's the "soft skill" of extracting a good specification from stakeholders.

What's the reason for the dysfunction here? It could be that the software development team is just overstaffed. Maybe if they had lower headcount, they wouldn't be idle so much of the time.

Of course, it could also be that there are too many stakeholders providing incompatible requirements and muddying the waters, and that there's nobody in a position to make a decision about the real requirements.

I think it's easy for an organization to misidentify an organizational problem as a technical problem, then throw more technical headcount at it while ignoring the underlying dysfunction. And this is how you end up with "bullshit jobs."

gsibble• 4 years ago

This is why I primarily prefer and frequently am the lead on backend APIs. There's no BS. I spend 90%+ of my time coding and architecting the system. No bickering, etc.. Here's the API, now use it. It's a great little niche.

rswskg• 4 years ago

Having recently disengaged from full stack/front end, I have to say that I agree with this.

pqs3• 4 years ago

All these meetings, reports, plans and apparently useless things, provide insurance to the different stakeholders of the project. Projects fail in many ways, and you need everyone to feel safe. That's why you need to document things a lot, in order to say “this was explained in section 3.2.1 of the manual” when the other team doesn't correctly use your tools. And this is true for everyone, the finance guys, the product guys, the programmers, the marketers, everyone. Providing insurance to everyone is very expensive, but it makes the large organization stable. If everyone worked like cowboys in an small company, then the large company would disappear in a large fire of infighting.

I never worked in a large company, but I work in academia, and we academics are also working on insurance a lot. The funding bodies want us to detail all expenses and justify all the changes in the plan, because they don't want people to say that the public funds are mismanaged. This is just an example. We also write tons of useless papers, to justify that we are productive with this money. This makes research very difficult. If you really want to do science, you should become rich and do it from home, like Nassim Taleb does, but in Academia we must work on all this insurance stuff, like in corporate world.

That's how things are.

phkahler2• 4 years ago

> The funding bodies want us to detail all expenses and justify all the changes in the plan, because they don't want people to say that the public funds are mismanaged. This is just an example. We also write tons of useless papers, to justify that we are productive with this money.

See how the solution is causing a different form of the problem it's trying to solve?

I agree with your premise, but sometimes I think having multiple efforts in parallel and letting many fail might be more productive than going the safe route.

frank_nitti3• 4 years ago

I could see that working for a set of moonshot efforts at startups who primarily only have to keep investors interested, or some subset of research projects at FAAMG companies with money to burn.

But how could that work with big companies making contracts with other big companies as their customers? Doesn’t seem like they could afford to just “let many fail” as they could lose the customer’s trust.

woojoo666• 4 years ago

Well the original article talks about how the work that a software company does in a year, can be done in a few months by a freelance developer with zero bureaucratic overhead. But which freelance developer? For every freelance developer that succeeds, there will probably be ten or a hundred that fail, or push out a mediocre product. This is what all the meetings and design docs and testing is for. To increase the chance of success.

I'm sure the same can be said for the academic world. If I was in academia and I was given funding without oversight, I would probably waste it all on researching things I found interesting but weren't necessarily useful to anybody. If you don't want to have to justify your expenses, then just fund it yourself.

HeyLaughingBoy• 4 years ago

multiple efforts in parallel and letting many fail

I actually worked for a company that did this for a while and the results were amazing. There were multiple tasks, each task being a way to improve or cost-reduce a part of the machine we built. Each task had 3 teams attempting to solve it a different way. We met back 6 months later to compare/contrast the outcomes. I've never seen so much innovation in such a short time. The job was a blast for those 6 months because you were only limited by budget (we had to build hardware) and imagination.

And then, of course, since it was a multi-billion dollar company, the entire thing got shut down and we went back to business as usual. But at least I still remember it 10 years later :-)

hcarvalhoalves• 4 years ago

I don't think it's about safety and stability at all, given how CEOs everywhere are _begging_ for their employees to innovate, be accountable and take risks. All this insurance is required because large organisations tend to devolve into "cover your ass" culture. People get automatically promoted by staying, so avoiding getting ousted by being someone's else scapegoat is the safest bet.

drewcoo2• 4 years ago

This. Incredibly risk-averse behaviors indicate an industry ripe for disruption.

poulsbohemian• 4 years ago

CEOs everywhere are _begging_ for their employees to innovate, be accountable and take risks

Executives like to say these things, but what they say and what they mean often diverge. The nail that sticks out gets beat down.

popcorncowboy• 4 years ago

provide insurance to the different stakeholders of the project

A good analogy. The lower trust the environment, the higher the levels of insurance required. But it's more than this, it's almost like the "busy work" is a form of "Proof of Trust", and the lower trust the environment the more Proof of Trust is required to be exhibited.

jrwoodruff• 4 years ago

It does seem like that's how things are. I wonder if it's how things have always been? And if not, what's changed?

pqs3• 4 years ago

This is a very interesting questions. I don't have an answer.

native_samples2• 4 years ago

Whilst I agree with a lot of what you say, this part:

We also write tons of useless papers, to justify that we are productive with this money.

doesn't seem to be a logical part of your argument. Writing useless papers is not a form of insurance nor proof that work is being done. It's rather the end product, what all the 'insurance' is trying to ensure gets done. The fact that academia outputs a torrential flood of useless papers has little relevance to the corporate world where the final product is, hopefully, useful despite sometimes being inefficient to get there. After all companies that produce truly useless outputs do eventually get the rug pulled from underneath them, either by bankruptcy or forced sale.

pqs3• 4 years ago

Yes and no. A scientist should generate knowledge and insight, the scientist must discover things. The only way to prove that to a bureaucracy is through papers. It should not be the end product, but it has become the end product. In any case, it is still insurance, if you publish cited papers, you are safe, even if their contents are useless.

d232• 4 years ago

I never worked in a large company

I don't want to be rude, but it sounds like you don't know what you're talking about.

It often goes far beyond "insurance." A lot of this stuff is performative. Some people simply aren't good at executing, and many managers are focused on appearances and increasing the size of their kingdoms. Most can't allow themselves to be fine setting a roadmap and having it execute smoothly. There are all sorts of other perverse incentives and absurd behaviors I could go into, but the notion that it's all completely rational is silly.

jenkstom2• 4 years ago

I believe (s/t)he(y) means in the sense of risk management. A lot of things are done to ensure that certain risks are minimized.

thawaya31133• 4 years ago

One of the big differences between a startup and a big company is that big companies have to make decisions about what to build. For a smaller company that decisions is already made. It’s the reason for the existence of the smaller company.

And the cost of making the wrong decision can be extremely high and it can be hard to both identify that it is the wrong decision and to reverse it.

With smaller companies if they make the wrong decision they will simply cease to exist, but in a larger company some other product (the one that made the company large in the first place) will cover for it.

This isn’t to excuse inefficient practices, but the idea that 100% efficiency (as defined by coding 100% of the time) or even a very high coding throughput is an unmitigated good is not really valid.

DantesKite• 4 years ago

What a great writer. He has a bunch of other insightful essays I really enjoy too. Thanks for the post.

darod• 4 years ago

programmers think their job is to write code, but their job is to implement solutions. sometimes those solutions involve pushing back and asking the customer to think about their workflow a different way, sometimes those solutions involve tweaking something existing or fixing a small bug, and other times those solutions require writing and fleshing out a whole new module/feature/product. the only way you know what the solution reduces the risk and provides value to your client is by communicating with them.

randomsearch• 4 years ago

I'm super sceptical of such articles. The hardest part of software development is knowing what to build, and that requires a highly skilled product manager. The latter is a full time job for even small projects with a handful of devs.

wly_cdgr• 4 years ago

He ain't wrong, in fact he's right. Being a kissless virgin he fails to appreciate the importance of UX/UI decisions. But other than that, yeah

TheBigSalad• 4 years ago

I get annoyed working with people like the author. "Make me code, don't make me think". I get that writing code is the most fun/rewarding part of the job, but it's not the actual job. Anybody can type, figuring out what to type IS the job.

johncessna• 4 years ago

After working at several large $techCompanyAcronym companies, I agree with the author's premise, but I don't agree that the time gets wasted in planning/bickering over color palettes. I also don't agree that there's a CYA culture in large companies, at least not at the front line worker level.

Here are a few issues I see:

A lack of achievable goals. They tend to be massive multi-year long initiatives. It's hard to feel any sort of urgency from a 2 year project. Even if it's broken into 6 month long chunks, it's hard to feel urgency given if you slip the first milestone, you've still got 1.5 years to go. Additionally, large projects suffer from analysis paralysis. I don't think this is a malicious thing, I think folks genuinely don't know what it is they need to do.

It's easy to hide in a large company. Generally, the longer it takes you to be productive the longer you can do nothing before getting noticed and/or actually terminated. An 8-12 month ramp up time is average in my experience. When the company only has 20 engineers it's easy to find the ones not pulling their weight. When you have 100k engineers, it way harder, and stack rankings, and the resulting hire-to-fire, are put into place.

Mandatory and optional training and non-work related events consume a lot of time. By non-work I mean things not relevant to the team's objectives. One could easily do nothing by participating in all the summits, trainings, meetings, wellness events, interviews, debriefs, design reviews, security reviews, etc.

exabrial• 4 years ago

Many

Most

plaguepilled• 4 years ago

I like my own space. I'm definitely introverted. But shit like this is inexcusably antisocial and I question why it was even posted.

You wanna be a s00p3r lean, high-volume company with actual impact? Good luck. 'Bloat' scales with accountability.

That's a bit invective of me so lets play out a scenario. Its not a real scenario - this never happens at an actual software company, because the incentives all hit each other at once and its not explicit. Its not even guaranteed to happen all at once!

But this drama does illustrate the incentives, to the extent I can demonstrate a point. Please read the below as an exposition rather than a testable hypothesis.

Lets say you wanna be a lean, multinational corp providing a crucial service to high paying clients. And you do it! Congrats, you, the lead dev, and a CEO who handles 'the rest' now have a strong user base, but also a lot of opportunities to be sued if your product is actually as crucial as you suggested it was and doesn't deliver. Wait.

Oops, you got sued, and you were (morally) in the right too! But fined all the same. It's a big fine.

'Never again' you and the CEO say. So now you need to hire lawyers, who advise you that to protect yourself legally, you need to monitor your service and have evidence that backs up your claims beyond 'we designed it to do that'. So now you have analysts! You are monitoring for uptime. For security. For correctness. Et cetera.

Now you have an analyst team and a legal team on top of dev.

But eventually your staff base grows. At some stage, payroll gets out of hand. An accounting division happens.

Accounting has many jobs. One such job CAN be to lower expenditure.

Accounting look at the COGs and notice that the dev team are spending money on a bunch of software but there's nothing written down as to what it does. They aren't expected to discuss their decisions with dev, so they don't.

So a budget is set up by accounting based on their expectations from similar industry. Spending on tooling is among those cut. Devs complain. Work slows. The analysts complain. The CEO is annoyed at the excess spending and the slow devs. The devs are mad at how out of touch the CEO is - after all, the accountants screwed up right? Why is the dev team to blame? Things were WORKING before! Why does she instantly take the analysts word as gospel?!

The CEO doesn't care about the devs or analysts to that extent though - she just wants the damn product to be shipped to spec so the company isn't sued again. But she recognises something needs to change.

The natural solution is to air everyone's expectations at once. A meeting is made to make sure these show-stopping issues don't show up and a cohesive company vision can be reached.

Devs have to spend time in meetings to help accounting, analytics, legal, and now marketing (since growth has slowed) not tread on their feet, and additionally prevent dev from treading on their feet.

Dev team is mad. Not only are they losing coding time, but now they feel bossed around by other departments. They were doing so much more before these other BLASTED LEECHES came in and spoilt everything. Something something 'I could do it better' something something. Cue 30 replicas of this article, complaining about Working With Other People. If you're lucky, there might even be a touch of Ayn Rand laced in. Or Marx! Truly a lottery of philosophy.

Eventually some devs break off and start their own schtick, and make a decent living for a while - maybe even for a lifetime, if the project is well scoped and managed!

But the less cautious startups? Well, if they don't deliver...

What was my point, aside from apparently being a hypocrite who can write edgy scenarios but is mad about reading them?

What i am trying to argue is that the other departments are there for an explicitly profit-generating or loss-mitigating reasons. And more than that: I'm saying this should be fairly obvious and that the dialogue needs to move on from this point.

More explicitly: I can understand working for a smaller company and enjoy the environment, but the constant whinging about megacorps being slow for devs and highly specialised/myopic is lazy thinking. Of COURSE they're slow. Of COURSE there's lots of documentation and meetings. You get paid a secure and comparatively higher wage for those inconveniences.

SassyGrapefruit• 4 years ago

It's not a charity. Spoilers your company is making money hand over fist. Many company's boast a $600,000 or more revenue per employee figure. In many cases you are there just for insurance. I employ more people than I need on purpose because someone might up and leave at any moment and I have to keep operations going

commandlinefan5• 4 years ago

All software sucks because deadline >>> functionality/usablity/accuracy. No matter how hard management insists that this isn't the case. In fact, the more they insist that it isn't the case, the more you can be sure that it is.

bradlys• 4 years ago

I have been in a company that is similar to one of these but the codebase was massive and very problematic - a good reason for why it was hard to get things done.

I think many folks here think if you work for FAANG or similar - it’s all cushy and you’re sitting on fat stacks but it just isn’t. You’ll get on a PIP real fast because you didn’t have impact - something which was out of your control because your boss assigned you a low impact feature. You’ll be kicked out within 1-2 years and back to the grind - meanwhile stressed and possibly underpaid because no refreshers and no salary bump.

Again - it sounds nice in some ways but it’s a mostly brutally toxic environment and the bar to get hired is exceptionally high. If you’re getting repeatedly hired at FAANG and crew - you’re in the top 1-5% or so and it’s a very competitive bracket to stay in. Seen many go in and never be able to get back in…

mc4ndr3• 4 years ago

Third week into a role. Managers too busy to meet. One reports that we have no product owner, no audience, and no requirements. The other demands a confident promise to deliver the app by Q3.

I recommend trimming the "MVP" to focus on just one, concrete user need, so that we have a prototype to deliver.

Manager: No, just stub 99% of the REST contract and get it to prod.

With each new software role, I feel I am somehow moving backwards compared to the relatively well positioned earlier roles.

phendrenad22• 4 years ago

I feel this too. At an earlier role we had a well-architected PHP codebase that we were throwing away and replacing with graphql, scala, and angular. I was a junior dev so they threw me into fixing the "unimportant" legacy PHP system (which just so happened to be the thing making money for the company) instead of the shiny new rewrite. Never been happier in my life.

AtNightWeCode• 4 years ago

I agree in general. But the business is not a joke. It is a farce.

Why have one time reporting system when you can have two or three? Why not also add some burndown charts to that so you must report every hour left of that ticket? Why not add an additional spreadsheet with the same info while you’re at it to get a “holistic view”? Make it two or three different spreadsheets btw so you can separate progress from work hours and gummy bears. Cause abstractions are important CS.

“Gummy bears” is of course named different in each project. Remember to not mix up the gummy bears with mentos and the skittles. Some random management person will get insulted otherwise.

Then the boss tells you to only work on the highest prioritized tickets. 2 minutes later the same boss mails you a side-quest that takes a day. Then the same boss asks why you have not only worked on the highest prioritized ticket.

Then you show the boss 5 tickets and ask: What is the highest prioritized ticket? The boss replies: They are all the highest prioritized. Then you start to work on one ticket and the boss asks about the progress on another ticket 2 hours later.

Then the boss calls you into a meeting. The meeting is set for just 20 minutes but you quickly realize that there are a lot of people in the meeting. The meeting is about some design that nobody was prepared for, so everybody must read up and improvise. 2 hours later it is decided to apply the same kerning on each heading. What the problem was or what the solution solves nobody knows.

Now you get an encouraging email about what success that meeting was. But the day before some marketing person without prior notice or permission managed to do a fundamental configuration change leaving the system offline. You fixed the problem and saved the company tens of thousands of dollars even though it was outside agreed work hours. Then you get criticized by the boss because “the system is supposed to work”.

And this just repeats over and over.

phendrenad22• 4 years ago

A single developer, armed with a correct and final specification, can build software far faster than a team. However, specifications are constantly changing, and are never complete, so the number of developers you need becomes infinite. FAANG have deep pockets, so they can push their efficiency from 99% to 99.9% by hiring another ten thousand programmers.

badrabbit• 4 years ago

I work in infosec and I have seen this problem quite a bit but not at every company. An advice I received early on was "better to ask forgiveness than permission".

So what I do once in a while is, if there is a major problem and the bureaucrats want to strangle it or play games like this, I just quietly do all the work and say "he, look! It's done!" Some will get a bit upset and inevitably my done work takes months to get reviewed and discussed before being implemented with no change.

It is not good for scoring political points but shit gets done. In normal IT or sofware dev, this just means delayed projects. In security it means reduced security posture. Bad guys are not taking months and years in meetings when they attack us. It in itself is a security risk and what I do to work around such b.s. in my opinion is remediating that risk.

But regardless of this, bureaucrats will still continually tear down and the build backup. Migrations the proof of concept meetings and demos. It is very hard to communicate with management that in infosec, you need to be agile and stable at the same time. Agile when responding to threats but stable in your tooling and people so you can develop maturity.

I too like job security and all that but damn it! I would feel so shitty if we get pwned and all we have is excuses.

bozobuttz• 4 years ago

I work in a devops role, and I also have the flexibility to work on fixing things that management does not deem a priority, typically when I get bored with my assigned tasks. I am much more motivated when things actually get done vs. revisiting the same problem over and over.

t_mann• 4 years ago

Wasn't Agile meant to address exactly the inanity of meetings described here? Interesting that the author doesn't mention it. But I guess the thirst of middle managers in large corporations for Gantt charts just can't be quenched.

tored• 4 years ago

One unfortunately thing is that the industry in general struggles with incrementally improve functionality within a product over time, this goes for product managers, project manager, software developers etc.

This is why everyone wants to make every decision up front, before you have enough knowledge about what you are building, with endless meetings instead of pushing it out and learn that way.

Software developers doesn't like it because that could mean large rewrites because of ripple effects.

Product owners fears that there won't be second chance to do things, thus try to cram in as much as possible early on.

Project managers fears it is going to be more expensive to revisit functionality instead of doing it once.

Many software companies are a joke

Related Stories