11 ms·

Astonishing to me that someone with 20 years' experience in any industry could have so little perspective. Obviously there are inefficiencies with big companie

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.

jokethrowaway 4y 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.
- batiudrami 4y 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.
- mschuster91 4y 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 4y 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.
- blowski 4y 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?
  - sirwhinesalot 4y ago
    We've figured out 20 years ago that writing code, showing the resulting program to customers and getting feedback was the most effective way to find out if you're actually solving customer problems. Some group of people wrote about it in something called the "Agile Manifesto" or some such.
    - blowski 4y ago
      How do you think an author of the Agile Manifesto would respond to the original article?
      - sirwhinesalot 4y ago
        Considering how companies are implementing the "Half-Arsed Agile Manifesto" rather than the actual "Agile Manifesto", I think reading this article might be what pushes them to jump off a bridge. 20 years of companies failing to understand your 4 line text, and using it to justify things that are utterly antithetical to what it stood for, has got to hurt. It's so simple: - Individuals and interactions over processes and tools - Working software over comprehensive documentation - Customer collaboration over contract negotiation - Responding to change over following a plan Sounds like an environment the author of the post would like, he even describes such an environment later on, one that he enjoys so much he overworks for no extra pay. Then there's the twelve principles, one of which is: "Working software is the primary measure of progress." Another one is: "The best architectures, requirements, and designs emerge from self-organizing teams." Another is: "Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done." Following bullshit company processes and pointless meetings is the opposite of the above. The one that might be contentious is: "Business people and developers must work together daily throughout the project." This sounds a lot like meetings, but that's the smallbrained take on it. Here's an easy alternative: Continuous Deployment in a staging area and a Slack/Teams channel for business people to comment on changes they feel are necessary. Not only does the request get recorded (often nothing gets documented in meetings) but the communication is asynchronous and doesn't require booking the entire team for hours. The discussion is also a lot more actionable because it is about something concrete. Given the above, what do you think about how an author of the manifesto would respond?
shortformblog 4y 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-acbc271ba78b https://liou28335.medium.com/why-i-dislike-open-source-acbc2... Something tells me he’s gunning for that Medium paycheck.
- op00to 4y ago
  Oh man, that open source article is hilarious! Thank you for sharing.
  - ljm 4y ago
    I haven't contributed to open source in a few months and I still can't find a date to take to Starbucks. What am I doing wrong?
- politelemon 4y ago
  > Medium paycheck. I'm sorry, what? Out of the loop here.
  - shortformblog 4y ago
    I’m referring to the Medium Partner Program, which pays based on level of engagement with readers, particularly subscribers (as this is a Medium post).
  - ethbr0 4y ago
    Find "What Stats/Data Points Will Be Used to Calculate Medium Earnings?" in the link: https://medium.com/blogging-guide/how-much-money-can-you-make-writing-for-medium-a3cf0c9c7533 https://medium.com/blogging-guide/how-much-money-can-you-mak... But basically: outrage increases readership increases Medium author payout
- mschuster91 4y 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 4y ago
Yep. I think the author fails to understand that coding is only a small part of the process of writing production software.
- rxhernandez 4y ago
  Do you think that sw engineers at startups aren't largely writing code for most of their job?
  - onion2k 4y ago
    I think sw engineers at startups very often write way too much code rather than spending time thinking about, and talking about, what to write. As the old saying goes, "you can save hours of planning by doing weeks of coding."
    - UK-AL 4y ago
      Most discussions at large corporations are bikeshedding. Huge issues are ignored, but some minor detail which can be changed easily later gets talked about for weeks. It's often because its a detail middle management can understand, but the huge issue isn't. You then have to spend a significant amount of time trying to guide people to focus on the right things. And that is draining.
- sdevonoes 4y 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 4y 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.
sshine 4y 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.
- mytailorisrich 4y 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.
  - watwut 4y ago
    And still, working in company that does not document what the system does, it sux massively more. Because end result is that no one knows how to use our own software. You dont know what it is supposed to do, so it is impossible to keep that stuff working. It takes ridiculous amount of time to configure anything or reproduce bugs, because you need multiple calls to find the one person who barely remembers. Also agile manifesto is 20 years old. Agile is literally what most large dysfunctional companies do these days. It does not have no new solutions to actual real problems of companies, because it is old.
    - 4y ago
jp0d 4y 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 4y 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.
- mrcartmeneses 4y 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.
  - 4y ago
ethbr0 4y 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.
- amitport 4y 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.
  - slumber86 4y ago
    >Sometimes providing a bad product is only relative to the competition (which may have a worse product). Eventually will came someone with a truly good product and distrupt the market
    - croes 4y ago
      Or this company is bought up, which was there first and therefore has the larger financial reserves.
Simon_O_Rourke 4y 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.
mschuster91 4y 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.
deleted 4y ago
[deleted]
mkl95 4y 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 4y 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_c 4y 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.
ljm 4y 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 4y 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.
xpe 4y ago
It is easy to confuse "so little perspective" with "a different set of values". This seems to be the case with ^.
xpe 4y 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 4y 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 4y 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.
ineedasername 4y 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 4y 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 4y 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 4y ago
3 years, 20 people, 24K LOC does sound objectively inefficient to me for the project as described.

jokethrowaway 4y 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.

batiudrami 4y 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.
mschuster91 4y 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 4y 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.

blowski 4y 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?
- sirwhinesalot 4y ago
  We've figured out 20 years ago that writing code, showing the resulting program to customers and getting feedback was the most effective way to find out if you're actually solving customer problems. Some group of people wrote about it in something called the "Agile Manifesto" or some such.
  - blowski 4y ago
    How do you think an author of the Agile Manifesto would respond to the original article?
    - sirwhinesalot 4y ago
      Considering how companies are implementing the "Half-Arsed Agile Manifesto" rather than the actual "Agile Manifesto", I think reading this article might be what pushes them to jump off a bridge. 20 years of companies failing to understand your 4 line text, and using it to justify things that are utterly antithetical to what it stood for, has got to hurt. It's so simple: - Individuals and interactions over processes and tools - Working software over comprehensive documentation - Customer collaboration over contract negotiation - Responding to change over following a plan Sounds like an environment the author of the post would like, he even describes such an environment later on, one that he enjoys so much he overworks for no extra pay. Then there's the twelve principles, one of which is: "Working software is the primary measure of progress." Another one is: "The best architectures, requirements, and designs emerge from self-organizing teams." Another is: "Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done." Following bullshit company processes and pointless meetings is the opposite of the above. The one that might be contentious is: "Business people and developers must work together daily throughout the project." This sounds a lot like meetings, but that's the smallbrained take on it. Here's an easy alternative: Continuous Deployment in a staging area and a Slack/Teams channel for business people to comment on changes they feel are necessary. Not only does the request get recorded (often nothing gets documented in meetings) but the communication is asynchronous and doesn't require booking the entire team for hours. The discussion is also a lot more actionable because it is about something concrete. Given the above, what do you think about how an author of the manifesto would respond?

shortformblog 4y 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-acbc271ba78b https://liou28335.medium.com/why-i-dislike-open-source-acbc2... Something tells me he’s gunning for that Medium paycheck.

op00to 4y ago
Oh man, that open source article is hilarious! Thank you for sharing.
- ljm 4y ago
  I haven't contributed to open source in a few months and I still can't find a date to take to Starbucks. What am I doing wrong?
politelemon 4y ago
> Medium paycheck. I'm sorry, what? Out of the loop here.
- shortformblog 4y ago
  I’m referring to the Medium Partner Program, which pays based on level of engagement with readers, particularly subscribers (as this is a Medium post).
- ethbr0 4y ago
  Find "What Stats/Data Points Will Be Used to Calculate Medium Earnings?" in the link: https://medium.com/blogging-guide/how-much-money-can-you-make-writing-for-medium-a3cf0c9c7533 https://medium.com/blogging-guide/how-much-money-can-you-mak... But basically: outrage increases readership increases Medium author payout
mschuster91 4y 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 4y ago

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

rxhernandez 4y ago
Do you think that sw engineers at startups aren't largely writing code for most of their job?
- onion2k 4y ago
  I think sw engineers at startups very often write way too much code rather than spending time thinking about, and talking about, what to write. As the old saying goes, "you can save hours of planning by doing weeks of coding."
  - UK-AL 4y ago
    Most discussions at large corporations are bikeshedding. Huge issues are ignored, but some minor detail which can be changed easily later gets talked about for weeks. It's often because its a detail middle management can understand, but the huge issue isn't. You then have to spend a significant amount of time trying to guide people to focus on the right things. And that is draining.
sdevonoes 4y 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 4y 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.

sshine 4y 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.

mytailorisrich 4y 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.
- watwut 4y ago
  And still, working in company that does not document what the system does, it sux massively more. Because end result is that no one knows how to use our own software. You dont know what it is supposed to do, so it is impossible to keep that stuff working. It takes ridiculous amount of time to configure anything or reproduce bugs, because you need multiple calls to find the one person who barely remembers. Also agile manifesto is 20 years old. Agile is literally what most large dysfunctional companies do these days. It does not have no new solutions to actual real problems of companies, because it is old.
  - 4y ago

jp0d 4y 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 4y 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.

mrcartmeneses 4y 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.
- 4y ago

ethbr0 4y 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.

amitport 4y 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.
- slumber86 4y ago
  >Sometimes providing a bad product is only relative to the competition (which may have a worse product). Eventually will came someone with a truly good product and distrupt the market
  - croes 4y ago
    Or this company is bought up, which was there first and therefore has the larger financial reserves.

Simon_O_Rourke 4y 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.

mschuster91 4y 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.

deleted 4y ago

[deleted]

mkl95 4y 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 4y 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_c 4y 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.

ljm 4y 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 4y 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.

xpe 4y ago

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

xpe 4y 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 4y 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 4y 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.

ineedasername 4y 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 4y 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 4y 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 4y ago

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