Many software companies are a joke(liou28335.medium.com)
liou28335.medium.com
Many software companies are a joke
https://liou28335.medium.com/many-software-companies-are-a-joke-9f4b10378c7a
368 comments
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.
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.
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.
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.
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.
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.
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.
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.
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...
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...
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.
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.
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?
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?
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.
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.
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.
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.
This isn't even necessarily inefficient, because productively doing work that isn't needed isn't helping anyone either.
Imagine actually caring, my aim is to get away with as little work as I can while still earning good money. ‘No nonsense coding and learning’ cringe, imagine actually liking to write software. After 11 years of embedded dev, I can safely say I rather not write a single line of code ever again. This whole industry is 99% bullshit. Thankfully I could exploit it for a lot of monetary gains
I agree 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.
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.
> 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.
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.
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.
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.
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.
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.
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.
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.
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!
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!
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.
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…
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…
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.
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.
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.
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.
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.
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".
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".
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.
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.
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.
Management could many times done better of course, managers are as lazy or incompetent as other people, if not more.
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.
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.
>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.
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.
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.
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.
"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.