20 ms·

Many software companies are a joke

• jleyank 4y ago
  These were not “software companies”. Such companies sell software. These were “normal” companies dabbling about automating processes and “being modern”. If software isn’t what keeps the lights on, it’s just a playground or a cost centre.
• Juliate 4y ago
  One of the main reason I have come to to make peace with that, is that these companies are not optimizing for delivery and product quality first. They are optimizing against risk (of change, of loss of control over the whole process from ideating to selling/shipping). If you can build the product/service in 2 months with a tight focused team of 3-5 people, in a 100+ engineers company, how do you manage if this 3-5 people leave (whatever the reason): how do you manage to infuse their experience/expertise over the thing they built, to 10/20/30 other people to mitigate then this risk? You can manage to do so when your company grows, because... you don't have a choice, you started small. When you've grown already, to mitigate this risk, you have to start to infuse things across many people and layers of people you have, so that when, 3-5 people leave, it's almost barely noticeable an event. Maybe there's a better set of reasons. But this one made me understand better the whole world of big corporations and especially (big) consulting sofware companies (which are often several ones contracted on the same big projects). Edit: you may also understand "optimizing for" as "scared to death about".
  • Juliate 4y ago
    That also explains the "design by committee" thing and the ugly/desperate UX some corporate apps have.
  • regularfry 4y ago
    That would be justifiable if the risk was proportional to the cost. Frequently it just isn't. As a case in point, if "when, 3-5 people leave, it's almost barely noticeable an event" then you've almost certainly over-compensated for the general case. Why? Because the entire set of people who know anything about a given project simultaneously leaving should be incredibly rare. If that's your benchmark event probability, and your risk mitigation costs are linear in the risk probability (which they probably are, by vague handwavy analogy to finance thinking), then you're constantly bearing costs that aren't justified by the downsides you're likely to encounter unless the specific project in question is company-breakingly critical. If an entire dev team up and leaving isn't a rare event, you've got deeper problems.
    • emteycz 4y ago
      This incredibly rare event has happened at almost every firm I've ever worked at (except small startups), multiple times a year (different teams/products, but sometimes also the same product with its new team)... Yeah they should fix the actual issue many layers above, but that's not something the guy planning for this can do at huge corporations. You just deal with whatever it throws at you.
      • regularfry 4y ago
        Interesting. I think I've seen it once in a 20-year career.
    • WJW 4y ago
      I think rather frequently the impact of such a "rare" event could indeed be company-breakingly critical, depending on which part of the company that team was running. As a thought experiment, if all DBAs left tomorrow and the database fell over the next day, how much time would the next-most-capable person need to figure out the backup policies and scripts, restore the db and bring everything back up? I've personally seen this sink a company outright. It's only anecdotal evidence ofc, but it is still something that happens. Worse, people leaving a team are not independent events. People leaving a certain team is often highly correlated to other people leaving the same team, because there is some common cause like a toxic manager.
    • Juliate 4y ago
      "should be incredibly rare". Not incredibly, it's rare, but it happens (seen it in two small companies, it killed them; saw it in several ESN/consultancy projects, it killed the contract, but was a manageable event in the whole company; saw it in medium software companies, it killed the projects and sometimes pushed for strategy changes). It happens enough for many (not all) individuals to have noticed across their career (especially when in management, where a big part of their role is already to manage risk). It happens enough for any single company to be quite traumatized by it when it happened, and to try to avoid it in the future. Where some companies do it differently is: they don't overreact, they understand that this is a risk management issue and that you can balance it, and/or they don't setup a "general case" for all projets/teams (depending on the type of the project). This requires quite some serenity and perspective.
  • jokethrowaway 4y ago
    I disagree. In most of the large companies I worked for there was zero documentation (+1000 employees, +100 engineers) or very very little or only in a few projects. When people were leaving, someone else was getting hit with a shitty undocumented project, they would spend some time learning it - and that was it. In the worst case a doomed-to-fail-rewrite started and troubled the team for a couple of years. I think the main issue is that: - People are given tasks from the board of directors (trickling down layers and layers of management), they don't feel like it's their problem - There is little accountability, tracking performance is very hard; tons of companies don't bother, but some of them do (after HR intervention, CTO being in trouble justifying the costs) and they can't find decent metrics to use for performance, so the bosses are basically flying blind / trusting middle managers. - No high growth stocks that will make you rich - Middle managers feeling like they need to prove they're doing something imposing weird and useless rituals: meetings, presentations, etc These factors allow people to slack off as much as they can and take as long as they can to do anything. As long as they can come up something for standup, it's all good.
    • Juliate 4y ago
      This does not look like disagreement to me, but rather a distinct perspective of the same thing (was it the issue, or the symptom?). Getting hit with a shitty undocumented or doomed to fail project is part of the problem/risk being managed or not: on some occasion, it can kill the team/project/company, on some other, it can be managed more or less successfully, but still in a way that is _not regular_ against the baseline. When you get a project handled by a larger team of people apparently doing "not much", 1/2/3 of these leaving will not change the baseline of the project they were working on (or if it does, then comes the pressure to reorganize again to avoid that disruption). It's "a bit" similar to the 40% lazy ants thing (https://boingboing.net/2017/09/12/living-larders.html https://boingboing.net/2017/09/12/living-larders.html).
  • sam_lowry_ 4y ago
    Here are a few personally lived counter-examples: 1. a unicorn where someone implemented a a CI/CD system that none else can work with nor comprehend 2. a public institution where dozens of people work against the clock to replace the software maintained by a few old farts close to retirement 3. a critical financial institution where secrecy and nepotism made anyone with 30+ years of service into a major failure point. IMO, the bigger the organisation, the more they are shifting from internal risk management to outsourcing all risk. When the risk is handled by third parties via contractual obligations, life get easy for middle management. Needless to say, many of those contractual obligations are not worth the paper they are written on. Many organisations survive largely on the good will of the lowest-rank employees.
• Negitivefrags 4y ago
  The sad thing is that it’s a joke that many people don’t seem to be in on. You get all these defenders coming out of the woodwork when people wonder what the hell all the programmers at say, Twitter, are doing. Supposedly you puny mind can’t comprehend the challenges of developing a website “at scale” The real answer is, almost nothing. People are being paid very high salaries to do nothing.
  • mike10921 4y ago
    Yup i recently worked at a company that had a lot of their base technology already built out. They hired a lot of new expensive talent and the talent was pretty bored so they made a big project to re-do all the existing technology that already worked pretty well. The results are less than good..
  • bigDinosaur 4y ago
    Nah, most people feel some guilt at doing nothing when they're paid well, so my guess is lots of internal projects that don't go anywhere and that we never hear about. That's quite different to nothing at all.
    • Negitivefrags 4y ago
      Oh I’m sure that it feels like they are doing something. But in a badly managed company each person is like a randomly oriented vector. You sum them together and the end result is something near to zero.
      • barrenko 4y ago
        It goes to minus something imho, wherein lies our problem.
  • baybal2 4y ago
    > The sad thing is that it’s a joke that many people don’t seem to be in on. On each of my job in my early career, I spent considerable effort weeding out people who got too used to such mode of work. There are software developers with vastly different prior work experience, and expectations. People who do 30 minutes of actual coding a day, and ones who do 11 hours in coding sweatshops. People who spent their entire career on 30 minutes of coding a day jobs, and think of themselves too much once they rise in seniority are the worst, and are the biggest source of dumpster fire/death march projects. My third serious job in Canada: work in a consumer electronics trading company, upgrading their shipping system to get shipment status from DHL API, and submitting new ones. My predecessor, and ex-unit head wasted close to $1m, and more than a year, got SAP involved, invited many consultants, change managers, a project management contractor, and just been in the process of "fixing deficiencies" of his work by buying "enterprise SOA solution." 23 year old me called this bullshit on the second week, fought to have a serious talk with the company owner, rewrote a 10 years old steaming pile of PERL, and BASH scripts to Python, Postgres, and JS frontend in under one week, showed it working, and countered "You don't understand SOA!" protests of the unit head in front of the boss. He gets fired, I get a bonus the size of my annual salary. Since then, my bosses always threw me as a "firefighter" on projects in crisis. ------------ We now have 2 major trends in the industry: 1. More, and more non-IT companies are trying to do software 2. A giant amount of newcomers to the industry who would've normally went working for banks, and management consulting companies eroding big IT companies as later grew with little regard to quality of hires.
• batiudrami 4y ago
  Astonishing to me that someone with 20 years' experience in any industry could have so little perspective. Obviously there are inefficiencies with big companies, but complaining about needing to do documentation, or basic project management? The writing is smug and shows no self awareness - it seems to me that the author cannot recognise that there may be other priorities than exactly what is in front of them and therefore everyone who disagrees with him must be wrong. It is good that the author has found something that suits them better.
  • 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.
• a_square_peg 4y ago
  I tend to think most of engineering is rather mundane but potentially very rewarding. I hate meetings and overly complicated project coordination just as much the next person but there is also danger in wanting to do ‘cool stuff’ - imagine a dentist who is passionate about pulling teeth out. A project that I quite enjoyed involved months of investigation work, finally solved by tweaking a single software parameter that dictated how far a release mechanism moved. The number of internal/external meetings I had to demonstrate that this can indeed fix the problem could have seemed silly but it was also very reasonable given the risks involved.
  • formerly_proven 4y ago
    > I hate meetings and overly complicated project coordination just as much the next person but there is also danger in wanting to do ‘cool stuff’ - imagine a dentist who is passionate about pulling teeth out. There was a case here were an (employed) dentist was apparently bored and started to drill and fill perfectly healthy teeth. Iirc, criminal charges were filed. Malpractice because bored (or feeling undervalued/underappreciated etc.) isn't just a problem for SWEs, but actual doctors. Also see: nurses and doctors inducing code blues to get to be the hero saving the patient; firemen becoming arsonists to have a fire to extinguish.
    • xpe 4y ago
      What are some estimates for the likelihood of these behaviors? In dentistry? 1 of every ... ? 1,000 teeth? More? Less?
      • pixl97 4y ago
        Not sure how many good studies there are on it, but the likelihood of an unnecessary operation occurring are strongly linked to that months financials. https://www.theguardian.com/society/2000/apr/16/futureofthenhs.health https://www.theguardian.com/society/2000/apr/16/futureofthen...
  • ethbr0 4y ago
    > imagine a dentist who is passionate about pulling teeth out That's a great metaphor for code-before-you-know developers. > finally solved by tweaking a single software parameter that dictated how far a release mechanism moved I think of this type of work as programming by other means. The problem couldn't have been "fixed" without all the discovery meetings and understanding. The "fix" couldn't have made it to production without political agreement. Is that computer code? No. Is it building a solution to interact with a complex system (of people), using the primitives available to you (less than VP-style "Just do it"), to realize a desired outcome? Yes. Others may be different, but I find hacking obtuse process problems and corporate political structures just as fun and rewarding as a nice piece of code.
• avereveard 4y ago
  > You will be asked to write a documentation for some little code you wrote. You will carry out tests. You will argue with your colleagues and supervisor on every decision you make. imagine thinking this is bad, unironically.
  • ratww 4y ago
    This is not what the article says, however. You misquoted in order to leave out the fact that the documentation is 50 pages, and some of the tests are useless, and arguing with colleagues is not always productive.
    • avereveard 4y ago
      I removed the obvious exxagerations. of course nobody ask you 50 pages, so why is it relevant for the discussion? and who decides for how much documentation is needed anyway? the producer, or who pays for it? also, you don't know which tests are and arent useless beforehand. code coverage may not be the perfect metric, but correctness is is semi-decidable anyway, so if one claims before hand that some coverage test is useless, he's most likely being lazy or drown in his self importance. and arguing technical decision is always productive, so much that rubbe ducking is an actual methodology becuse even arguing alone is better than go head down with aggressive randomness.
      • ratww 4y ago
        Sorry but you are wrong. Useless documentation, useless tests and useless arguing definitely exist, period, and they are tautologically bad. Maybe you haven't had the experience of working in such an environment where those things happen, but claiming they don't exist and twisting someone's words is absurd. Also, those wild uncharitable and provocative interpretations are also against the HN guidelines.
        • avereveard 4y ago
          I'm not claiming they don't exist. I'm claiming they're not universally bad, and that the claim they're universally bad is absurd - if unsure about the interpretation, please do refer to the initial post - you might want to start applying that charitable interpretation thing.
• oxff 4y ago
  I think the inflation / funny money being injected doesn't help at reducing fake working.
  • ratww 4y ago
    It definitely doesn't. I worked in the past at a company where Softbank asked for the dev headcount to be increased as a condition of the funding. Lots of teams ended up being responsible for halves of pages, half of a microservice, etc.
• Lapsa 4y ago
  my favorite - forcing signing "Code of conduct" that pretty much says you gonna try to be a good person (as if you were not beforehand)
  • 867-5309 4y ago
    "Tame in me the tempers four, that I may serve thee evermore. Place in me the values nine, that I may feel thy touch divine."
• williamkuszmaul 4y ago
  I think that many "software companies" are actually marketing companies that plan to make almost all of their profit from a product that has already been built. They're not necessarily a joke... it's just that software engineering is no longer their main business.
• lnxg33k1 4y ago
  I think I had more or less the same conversation with a coworker recently, I also have 15+ years experience in building software and I think that software is useless and the point to build a project by itself in 5 months is naive, software developers have a value if the thing they’re building serve a purpose, and the purpose needs to be defined through meeting people with the domain To me this post has junior dev perspective but also the coworker I had the conversation with is in his 40s and I’m starting to think there is some generational thing going on here
• secondcoming 4y ago
  > Believe me when I tell you that I could have worked on the entire software myself in 5 months Sure. People always over-estimate their abilities, and under-estimate problem complexity. It's easy to say something like the above when you're already looking at the solution.
• amelius 4y ago
  It's a sad thing that there is so little money in making scientific software; better make some dumb flashy app if you want to retire early.
• bayesian_horse 4y ago
  Finding out what needs doing - through meetings, documentation and so on - is very much a part of software development unless there is only one developer and he is also the only stake holder. This isn't even necessarily inefficient, because productively doing work that isn't needed isn't helping anyone either.
  • genezeta 4y ago
    One place I worked at some years ago... We had this "important project" coming up, a certain big feature that was wanted in the platform. A project which would take about 6-9 months with the collaboration of various teams across the company. I was involved but only in a helping role. One member of my team was involved but they were fairly inexperienced and so I was asked to go in as support. After the first two meetings a number of things became clear. Mainly that the product owner for the project was extremely ambitious, clearly not knowledgeable about the technology involved and got very upset about any concerns or problems anyone would point out. They wanted "those stupid meetings" to be just for informing them of solutions and progress, not for discussing problems and options. At the third meeting I made the mistake of mentioning that a particular detail, not too important, would be extremely costly to do as asked and that we would be better off doing it in a much simpler form. Unbeknown to me, that day the product owner went behind my back and asked for me to be immediately removed from the project. So I was. I didn't care much for it and I only learnt about that move much later, when I had already left the company. Anyway, the project ended up taking about 2 to 2 and 1/2 years and it had to really reduce its scope in the end. And some of the people involved confessed that it was because of the product owner, because they had wanted people to "just build this thing I say and stop arguing". A lot of work was simply thrown away several times simply because of not having had the proper discussions it needed.
    • lupire 4y ago
      Yes, some product managers or whatever are terrible at there jobs, just as some programmers/engineers are. Doesn't mean the job role is useless.
      • 4y ago
• lurker531 4y ago
  Imagine actually caring, my aim is to get away with as little work as I can while still earning good money. ‘No nonsense coding and learning’ cringe, imagine actually liking to write software. After 11 years of embedded dev, I can safely say I rather not write a single line of code ever again. This whole industry is 99% bullshit. Thankfully I could exploit it for a lot of monetary gains
  • reallscoliosoi 4y ago
    I agree. Actually, I have never met anyone who has liked writing code. How much code do any of these high profile programmers even write anymore? Linus, etc? If the leaders of the industry don't even write code, it says a lot.
    • aurbano 4y ago
      I've been writing code for 16 years, which is now over half of my life. I've been a full time software engineer (now lead) for the last 9 years. I've been in similar situations to this article where most of my time was spent in useless meetings that I disliked, I tried to improve things, to focus meetings, to improve our efficiency. And all that aside I still love coding. Granted not all types of code, not the one I have to write sometimes at work. Just now I'm starting another little fun side project that I've been coding on my free time these last few weeks. All this is to say that coding is just a little tool, what you build with the tool is what can be fun. I think it can be healthy to write code that does fun things from time to time, even if the code you write at work is for the most boring aim.
    • Der_Einzige 4y ago
      I'm glad someone else said it. I want to think of problems that other people write the code to solve for me. I'm so tired of having an idea and no one but myself to work on it. It's led to a nice GitHub portfolio but I'd have rather that the stuff I built had existed already. This is mainly because most other people can execute with a better level of completeness than I can in the context of open source dev. This is mainly because I don't actually like programming, but I sure as shit love the niche I am programming for...
• reallscoliosoi 4y ago
  Every company I have worked at has been the same - very depressed people who have no enthusiasm for anything slowly dying as they sit there staring at the computer. It is in stark contrast to the physical labour jobs I have had, which have been very lively and happy places to work. I think the assumption that these people want to program for more than 2 hours per day is probably wrong, and you will just burn yourself out trying to do 8 hours of programming every day. In fact, many of these people burnt out long ago and just try to find anything other than programming to do. I wonder though, it is true that these companies are very inefficient, yet they never get taken over or superseded. Why can't the group of rogue programmers that are more productive take over any of these companies?
  • mellavora 4y ago
    Interesting observation. I wonder how much of the difference is between high physical activity, where often the work requires multiple people manipulating the same physical object (I hold the door, you attach the hinge), vs low physical activity, where often the work requires multiple people manipulating highly abstract concepts with purely imaginary connections (I write the API, you write the caller).
    • ethbr0 4y ago
      The physical/non-physical distinction might be a bit of a red herring, as this seems more a differentiation between repetitive and non-repetitive work. I.e. assembly line worker vs carpenter I'd hazard most people tend to dislike repetitive work, if they have the choice.
      • bigDinosaur 4y ago
        Yes, although repetitive physical (exertive) work is a bit less soul destroying if only because it makes you too tired to think about it too much.
        • ethbr0 4y ago
          As someone who has dug ditches in Georgia clay, agreed. Although I guess even the most repetitive physical task still has infinite physical fidelity, if you look for it. E.g. digging a hole in the same place 50 times vs writing the same code 50 times.
• mihaaly 4y ago
  Software engineering is a group effort with lots of components other than coding. It is very very seldom a lone operation and all those are tiny products with tiny scope (if results in a viable product at all!). Deciding upon the features, figuring out what is the best to do in a plethora of criteria involving finance, technology, organization takes much longer than the actual coding and involves the communication (spoken, written, presented, etc.), no suprise there. Management could many times done better of course, managers are as lazy or incompetent as other people, if not more.
• gray_50 4y ago
  I've worked at all company sizes from big tech, scale ups, and early stage startups. From my experience, I've learnt the most and done a lot of interesting work when the company size was smaller. Although a lot of people seem to care most about what I did at the big tech company and get surprised when I tell them I spent the whole sprint fixing some line on some sub menu.
• agounaris 4y ago
  I was expecting to find some interesting thoughts on this one, but its the usual rant of the "freelancer" who does not understand what production means! Yes big companies have productivity issues, however they have to create software which will outlive most engineers working at the business. You cannot reach the SLOs of google by hacking something together in 2 months!
• ZephyrBlu 4y ago
  I was reading https://danluu.com/sounds-easy https://danluu.com/sounds-easy again today, and when reading this article I was reminded of a particular section: "Everything we've looked at so far is a technical problem. Compared to organizational problems, technical problems are straightforward. Distributed systems are considered hard because real systems might drop something like 0.1% of messages, corrupt an even smaller percentage of messages, and see latencies in the microsecond to millisecond range. When I talk to higher-ups and compare what they think they're saying to what my coworkers think they're saying, I find that the rate of lost messages is well over 50%, every message gets corrupted, and latency can be months or years" Dan goes on to say: "When people imagine how long it should take to build something, they're often imagining a team that works perfectly and spends 100% of its time coding. But that's impossible to scale up. The question isn't whether or not there will inefficiencies, but how much inefficiency. A company that could eliminate organizational inefficiency would be a larger innovation than any tech startup, ever." Communication scales extremely poorly compared to code and large organizations require a very different skillset than small companies. The author seems like someone who just loves writing code as opposed to wanting to deliver maximum business value (As defined by the company), so it makes sense he dislikes big companies. There are also good and bad big and small companies. A well run big company is still going to have a large amount of communication overhead vs a small company.
  • snarf21 4y ago
    Well said. I think the key point you make is that we are paid to maximize the value of the business. If the business isn't profitable, we could all lose our jobs. Too many IC feel that if the company isn't maximizing their personal effort they are inefficient and wrong. However, sometimes more value can be added by NOT writing more code or more documents. It is sometimes more valuable to throw away a bunch of completed work and not fall victim to the sunk cost fallacy. Sometimes a "worse" architecture is the highest BV.
    • pydry 4y ago
      It's kind of trite to say that though. It's the business's job to ensure that the skills and resources at its disposal are put to good use, not yours. We're not all a bunch of mini CEOs.
• achow 4y ago
  There seems to be unnecessary vitriol towards the author. What he mentions about big financial companies (where software are for internal workflows) that is the life, and there are many of them and they are usually big employers. And what he says "You see, we were always busy but seldom productive" is actually the essence of 'Mythical Man Month'. About FAANG/MAANG, I have seen brilliant college toppers mucking around with html tags (but not able to get them right). High salaries to a lot of software worker is a joke indeed.
  • zcbenz 4y ago
    I feel really sorry for the author, what he said does not deserve such mean comments.
• t43562 4y ago
  Working with larger and larger groups of people gets harder and big companies don't have all the solutions - fortunately - because otherwise little companies wouldn't have a chance.
• mjburgess 4y ago
  The issue the author is talking about, in my view, is caused by the natural lifespan of corps tending towards bloating middle-management. (Very hard process to fight). At the start the founder group are rutheless productivity-chasers. Then the corp expands to include the its-just-a-job group. Everything ticks along well, and at some point, the rutheless can't manage the group. So they hire followers to listen to their orders and thereby manage others. In this sense middle management is really "corporate following". Now you have the its-just-ajobs, rutheless-productives, rutheless-leaders, and leader-followers. When the corp grows too far the balance in these populations is thrown way off (by, often, the shortsightedness of the real leadership in balloning middle-management to cover for them). At this point all the meaningful decisions are still held by the exec, but middle management are now so large they have to "find something useful to do", which is regulate all the meaningless decisions. At this point most of the ruthelessly-productive leave, and you're left with the justajobs, leader-followers and the few clueless productives who'll destroy their mental health trying to grapple with it all.
  • milkshakes 4y ago
    this is the gervais principle
    • mjburgess 4y ago
      Same phenomenon, slightly different analysis. The gervais-style analysis mystifies some of the issues it describes. The heart of the group dynamics is "leader vs follower", "rutheless vs clueless" and "transactional vs passionate". A startup is largely "passionate rutheless leaders", it grows to include "transactional ruthless followers" (its-just-ajob), then to "passionate clueless followers" (middle-management). At this phase its highly stable... you hire in "passionate rutheless followers" (ie., more actual workers)... who also need more middle-management... and at somepoint this becomes unbalanced due to poor executive incentives. That gives you your large population of "passionate clueless followers" (ie., middle-management), and the death of the productive phase of corp. action, into a more rent-seeking (or death) phase. In gervais, "losers become sociopaths" in a mystifying way; and likewise the "clueless" population is inexplicably unpromotable. My breakdown, for example, clarifies why: the "clueless" population never become rutheless-leadrs as they arent leaders at all. They're followers. I think muddling "transactional" dispositions with "rutheless" ones also mystifies the issue, under gervais, the "noble sociopath" is hard to explain. Really, its that they're both passionate (internally motivated) and rutheless. --- NB., rough definitions: "leader vs follower" (I command vs. I am commanded), "rutheless vs clueless" (success requires it vs. virtue requires it) and "transactional vs passionate" (external-reward vs. intrinstic-reward).
• gherkinnn 4y ago
  I get the frustration, but this reads like Programming Sucks [0] without the wit. 0 - https://www.stilldrinking.org/programming-sucks https://www.stilldrinking.org/programming-sucks
• dairylee 4y ago
  > I remember we would choose to work overtime due our addiction to the problem we were solving Oof, sounds like the author is the joke.
  • modo_mario 4y ago
    Why? From his description it sounds like he enjoyed it and that's probably the best kind of work. I've spent more time on tooling for myself than i got out of it in saved time and learned a ton without pay. Alternatively i'd have been paying a match of a videogame that i'd have forgotten about by and probably regretted now. These past days I spent a lot of time doing research into and designing an own keyboard at home. Something similar exists but is imo overpriced yet i'm not even saving money given all i've spent on a soldering iron, etc But i'm enjoying myself just creating something that i've gotten invested in. Meanwhile at work I feel like a damn clerk. Making minor changes, arguing, pushing little bits of overhead out of the way and working slowly on something i consider an inherently inefficient design bound to require a complete rewrite at some point for reasons out of our control. I wish i could go back to those occasional few problems I cared about to work just that bit more to get it working. In neither scenario I really cared about the overarching company but if there was never ever anything to catch my drive like that i'd have changed jobs by now.
    • dairylee 4y ago
      > Why? From his description it sounds like he enjoyed it and that's probably the best kind of work. The work will still be there for him the next day, there's no need to work overtime on it.
• praptak 4y ago
  TFA uses exaggeration to paint things which are necessary as superfluous bullshit (write a 50-page doc on every feature). When you strip that, you are left with a pretty banal statement: lone coder outside corporate environment can work faster on implementing stuff than one working on a big project in a corporate setting. Okay, but doesn't everybody know that already?
• gandutraveler 4y ago
  I've been in software for 20ish years now and I can tell you that beyond couple of years of learning, there isn't anything new to learn in software. Every few years same old patterns get wrapped under a fancy name and people jump into it thinking it's something cool to learn.
  • xtracto 4y ago
    Right? Young devs are just learning at the marvels of static typing languages (python, ruby and type script static typing efforts).and then, "server side rendering" (you mean like, PHP?) and whatnot... Having been programming for 30 years I find most of it pretty funny.
• rob_c 4y ago
  Dear author, you're one of those people who are capable of more and need to take an unfortunate step back. Given there are so many people who flocked and are still flocking to IT based programming jobs because of the promise that "one day you will be the next <insert-billionaire-here>" level push. I've met people who burn themselves out trying to write hundreds of lines of good code in a day. I've had new colleagues come in, publically slate my code, only to have to retract their comments in private several months later once they actually understood what it's doing. The author is probably one of the types, that left as seniour architect could have build something better with people around him adding polish and other "perceived value" to a customer. (Perceived value in this case being everything from corporate branding to translations to internal tooling). Most "complex" problems from the non-IT world don't need a full stack all singing all dancing latest npm, all the RAM in the world and a full Oracle site lisence. Most could be solved by some talented coders (3 or 4 max) doing the grunt of the work with others around them adding perceived value to allow the company to add a zero to the net value of the product, and it could be deployed in-house on a 2nd hand server with redundancy built for <$30k for it's whole lifetime. And that's assuming it's not just an app to sell that requires no hosting.
• zmmmmm 4y ago
  Another take on it is that in a big company, even incredibly mundane and boring software can scale to a level that is stupendously valuable once it goes into production. Hence the company can completely afford to have an entire team working away writing 3 lines of useful code a day. It is way more important that the code is created in a way that can mesh with the rest of the giant corporate behemoth (so yeah, documentation, meetings, etc etc) than it is that it is done fast.
• albertTJames 4y ago
  The guy made "only ennemies" in big companies. Not sure he'd be the most unbiased person to comment on the quality of tech jobs or somebody who can comment on healthy coworker relations. When the same pattern keeps happening to you wherever you work, its not them, its you. That you had a few good positions in healthy teams does not make you a healthy coworker, the culture was probably just too strong and healthy for you to mess it up.
• da39a3ee 4y ago
  You have to learn to say no to pointless meetings. It's true that there are many stupid people who will try to hold them and they have to be corrected. Usually saying "I won't contribute anything valuable and nor will I gain anything valuable, so it's not the right use of company resources" will suffice. This means that you have to develop your skills so that you are not scared of acting like that (not scared of being fired). It's ok to be fired / leave a company -- the goal is to not be scared that you can't get a better job if they fire you for pushing back about meetings.
• Joel_Mckay 4y ago
  Sometimes entrepreneurs start a company as a joke hobby while working in a coding pressure-cooker. Then a decade later end up growing up with clients in a completely different sales field. For sure, it is easier to complain, than to take responsibility. =)
• mattwilsonn888 4y ago
  What is this mythical concept "Business Value" which floats around undefined, unquestioned, in the impassioned rebuttals to this post? If I can hire one person instead of ten to finish software in one third the time, even if it needs significant tweaking by the end, is that not "valuable" to my business? Please define and expand your terms.
  • drdrek 4y ago
    His Dilbert level insights about corporate life are very old... running a business is complex and gets less efficient with size, that is no great wisdom. Building a code project with one person is great but consider the following issues: 1) Making sure the software is built to specifications 2) What happens if he leaves? 3) What happens if another urgent project arrives 4) Who will do support? 5) Who writes documentation 6) What about integrations with other systems in the business 7) What about IT/DevOps and server maintenance? 8) What about communicating it to other people in the org? I'm sure we can find more. The generic use of term "Business Value" in this instance means that while development time is indeed a measure of efficiency it is only a small part the overall value that a company needs in a project. Just to make sure I'll state again, large corporations are indeed not very efficient, I do not argue that, but they are profitable.
  • dahart 4y ago
    Business value is defined by the business in question, and what’s valuable to one business isn’t valuable to all businesses. The point is that the goal is a collective goal and not an individual goal. If you really can hire fewer people to get the job done, and the value you care about is lowering the costs of employing people, that certainly is valuable, and you should do it. Business Value is a term you learn to understand very quickly and deeply when you start a business and hire some opinionated programmers who complain loudly about having to talk to others and document what they work on, and proceed to have trouble meeting their deadlines, or create issues that others need to help fix. I’ve personally watched what happens with programmers who write code without talking to people enough, both individual programmers who seems prolific, and groups of programmers working on different parts of a larger system. When programmers refuse to stay involved in the discussion of what do to, they sometimes invent or imagine their own requirements, and they build things that don’t fit into what the business actually needs. This can be a colossal waste of time and money, even though all programmers involved were happy and felt like things were “efficient”. The problem with the article is that the author is arguing for personal efficiency, at the expense of group efficiency. It’s funny to write something about software companies being a joke and then argue that it’s annoying to work with other people. The software companies that are a joke are the ones no longer in business.
• drdrek 4y ago
  Companies are a business and not academic or artistic institutes... while developer wellbeing can contribute its not a goal on its own. If those 20 employees work on a bullshit project that could be done in a month, but at the end of the day generates tons of revenue its a good business endeavor. Could it be done more efficiently? Sure. Is it a better business venture than a work of art C++ code that was done super quickly but made no profit? Also yes. He has some good points hidden in there but his developer centric view is so 90's I wonder if he was wearing a jeans jacket writing this.
• ChrisMarshallNY 4y ago
  They are correct. It doesn't matter, and nothing will change in large corporations. That's not a bad thing, or a good thing. It's just the way things are. I spent most of my career in large corporations; many of those years, as a manager, where it was my job to maintain all that overhead the author complains about. I'm quite aware of the need for it, and a good part of my job, was trying to streamline the overhead, and shield my coders from it, so they could get more coding done. Nowadays, I work on my own (mostly), and the difference in productivity is amazing. I remember when I first read The Agile Manifesto, I was, like, "These guys really get it!" It was a dawn of a new era. The scales fell from my eyes. There was hope! There was a light at the end of the tunnel! The headlamp of the 5:15 Express, out of Sheboygan. Seeing how "Agile" is being implemented in corporate (and also small corporate wannabe) shops kinda took the wind out of my sails. But large corporations seem to get done what they need getting done. Very often, it's fairly "klunky" stuff. But that gives small shops an "in." If they can speak to the customers of these corporations, they could make some sales. Then...it comes time to scale. Let the meetings begin...
  • ejb999 4y ago
    >>Seeing how "Agile" is being implemented in corporate Dictionary definition of agile: "able to move quickly and easily." There is nothing 'agile' about how 'Agile' is being done in most/many big corps - yet another buzzword sold by high priced consultants who like buzzwords, to top-level execs that think they know what they want.
    • knotofvipers 4y ago
      One large corp I worked at, agile was really just an excuse to use minimum viable products in production. We were agile until this shitty software was in production and then we would move on to the next project. That was literally what we were calling having a startup mindset.
• mmcgaha 4y ago
  This is why a lot of programmers work after 5:00 PM. You can get more done between five and nine than you can get done all day.
  • lurker531 4y ago
• bumpyliquor 4y ago
  >> we were always busy but seldom productive that. My experience as well. Not on FAANGs but on quite a few multinationals. >> You will argue with your colleagues and supervisor on every decision you make and that. Politics are through the roof and driving out the good productive engineers. The people that have little to offer on the tech side though thrive in this environment creating a vicious toxic cycle.
• ineedasername 4y ago
  >if we should display certain data using a particular chart Why are software devs bothering with that to begin with? It seems like it should be something the user decides, even if they say something like, "I want a sparkline chart but make it real big and applied to all the data". And then I silently think to myself "oh so you want a regular chart but you heard the word sparkline once but don't know what it means. Okay, will do." edit: to be honest my users are reasonable and that sort of example is rare.
• varjag 4y ago
  There's one competent programmer for every 4.2 big thinkers, visionaries and non coding architects, so this is a natural order of things.
• spamizbad 4y ago
  > I remember while I was working for a big financial firm as a software developer. I kept asking myself why we were doing very little coding. Most of my time was spent attending useless meetings, preparing boring slides, making goofy excel sheets and Gantt-charts and maybe 1–2 hours of coding a day if I was even lucky. The software that I and my team worked on was a basically a javascript web application that monitored and collected details about financial transactions in the company. Believe me when I tell you that I could have worked on the entire software myself in 5 months. The entire solution could not have been more than 24,000 lines of code (including lots of generated code). My team spent nearly 3 years building this software, most of the time spent in meetings, bickering over the pettiest feature like, if we should display certain data using a particular chart and what colour the chart should be. Theoretically a Product Manager solves this problem for you: they are given the authority to be decisive about the details of a project, its scope, and they sit through all the boring meetings and manage the status update bureaucracy while working with the developers to actually build something.
• miav 4y ago
  As the top comment points out, the author comes off as arrogant and their view is unbalanced, but they do have a point. I find the saying "What a programmer can do in a month, two programmers can do in two months" is quite true. I consider myself competent and the people I work with are even more so, but human communication is always very imprecise and slow. If you stack it into a hierarchy of teams and managers, efficiency loss becomes exponential. I really do think that the best way to organize software development is to have discrete components with exactly one person in charge of a component. Of course there are notable downsides. If only one person is in charge of a component it would become quite opinionated and it would be difficult for devs to spot each other's errors, but I think it would be a great tradeoff nonetheless. I really don't want to spend even 5 minutes of my life debating whether we should split a folder into 2 smaller folders or not. I'd much rather have any member of the team go with their gut on this. An individual's choice may not be as good as that of the entire group, but it's good enough.
  • rrdharan 4y ago
    This approach involves a high degree of risk, i.e. your bus factor is 1: https://en.m.wikipedia.org/wiki/Bus_factor https://en.m.wikipedia.org/wiki/Bus_factor
    • miav 4y ago
      Yes, absolutely. Having a single person do what they want with a component involves risks but I think they can be managed. Say the dev in charge of an important component of a service is struck by a bus and dies. The optimistic scenario is that the code was well enough written that people developing adjacent components (ie. components that interface with that of the deceased dev) can effectively take over development in the short term until a new owner is found. A more interesting scenario is that in which the dev abused autonomy and the component is utter spaghetti. In all but the most extreme of cases, the component could be kept in maintenance mode as is for some time. This would block progress that relies on changes in the component, but allow the service to continue working. In that time, other devs could either untangle the spaghetti and refactor the code into something workable or rewrite it. In both cases a significant amount of resources would be spent, but this is a scenario that's unlikely to occur often and the fact that the component was owned by a single person places a soft cap on the size of the component (and ideally an employee would maintain a couple of unrelated components to ensure they can continue working if one service is deprecated) ensuring it could be replaced within reasonable time.
• thenerdhead 4y ago
  Here's something I learned. Yes working in big tech or a big company can have its fair share of red tape. You can either accept this and work as a cog in the system, or you can start to poke the sleeping bear. When you're overburdened with more meetings than time to do the work you talk about in those meetings, that's really on you, not the group of humans we call a company. If your boss starts to attach your performance towards meetings, then maybe its time for you to have that conversation about how nothing is getting done and that by not accepting meetings is how you do get stuff done. It's all about balance at the end of the day. Most people are reasonable and will listen. So while big companies may never change in practice, you can change how you work in a big company and see tremendous results by just saying "No" every so often. Most of the time nobody notices or cares, and when they do they respect you for protecting your time to do meaningful work.
  • 100011_100001 4y ago
    I 100% agree. It's about creating your own oasis. There will be friction from everyone around you, the only way to overcome it is by producing results and being very clear about your intentions. Also don't be surprised if your manager / co-workers around you forget agreements that have been made. Occasionally you might have to compromise, other times stand your ground. Moreover there is a fine line between poking the sleeping bear and acting like a prima-donna because things are beneath you. You can't always work on the most complex, or interesting projects. Someone has to fix the defects, produce the blue widget, now that the red widget is working. Personally I try to alternate between working on "cool" things and a boring but relatively important thing. That way I support the team, but also make 10x progress on some things. Meeting wise, I block out 4 hours a day (if I can) in my calendar. If you are using Microsoft Outlook you can setup Focus time. There are days that I do end up going to meetings during my focus blocks, but I consider it a choice. Of course I have had multiple honest discussions with my manager to manage expectations on both sides. Figuring out your manager's main needs / goals can help a lot in those discussions.
• j_barbossa 4y ago
  > Believe me when I tell you that I could have worked on the entire software myself in 5 months. I find this way of thinking very short-sighted. It may be true that this application can be written in net time in 5 months, but much more important than writing code is to know clearly what is needed, what users need. Moreover, requirements and wishes change over time. I have seen more than once that months of development time were wasted on something the users didn't need, so good product managers and senior software engineers who question things are often more valuable than engineers who write hundreds of lines of code a day.
  • JeremyNT 4y ago
    I think the problem here is that the company has software engineers sitting "idle" without any good requirements. I don't think it's uncommon at all. The "hard" part of almost every project I work on isn't the ultimately the code, it's the "soft skill" of extracting a good specification from stakeholders. What's the reason for the dysfunction here? It could be that the software development team is just overstaffed. Maybe if they had lower headcount, they wouldn't be idle so much of the time. Of course, it could also be that there are too many stakeholders providing incompatible requirements and muddying the waters, and that there's nobody in a position to make a decision about the real requirements. I think it's easy for an organization to misidentify an organizational problem as a technical problem, then throw more technical headcount at it while ignoring the underlying dysfunction. And this is how you end up with "bullshit jobs."
• gsibble 4y ago
  This is why I primarily prefer and frequently am the lead on backend APIs. There's no BS. I spend 90%+ of my time coding and architecting the system. No bickering, etc.. Here's the API, now use it. It's a great little niche.
  • rswskg 4y ago
    Having recently disengaged from full stack/front end, I have to say that I agree with this.
• pqs 4y ago
  All these meetings, reports, plans and apparently useless things, provide insurance to the different stakeholders of the project. Projects fail in many ways, and you need everyone to feel safe. That's why you need to document things a lot, in order to say “this was explained in section 3.2.1 of the manual” when the other team doesn't correctly use your tools. And this is true for everyone, the finance guys, the product guys, the programmers, the marketers, everyone. Providing insurance to everyone is very expensive, but it makes the large organization stable. If everyone worked like cowboys in an small company, then the large company would disappear in a large fire of infighting. I never worked in a large company, but I work in academia, and we academics are also working on insurance a lot. The funding bodies want us to detail all expenses and justify all the changes in the plan, because they don't want people to say that the public funds are mismanaged. This is just an example. We also write tons of useless papers, to justify that we are productive with this money. This makes research very difficult. If you really want to do science, you should become rich and do it from home, like Nassim Taleb does, but in Academia we must work on all this insurance stuff, like in corporate world. That's how things are.
  • phkahler 4y ago
    >> The funding bodies want us to detail all expenses and justify all the changes in the plan, because they don't want people to say that the public funds are mismanaged. This is just an example. We also write tons of useless papers, to justify that we are productive with this money. See how the solution is causing a different form of the problem it's trying to solve? I agree with your premise, but sometimes I think having multiple efforts in parallel and letting many fail might be more productive than going the safe route.
    • frank_nitti 4y ago
      I could see that working for a set of moonshot efforts at startups who primarily only have to keep investors interested, or some subset of research projects at FAAMG companies with money to burn. But how could that work with big companies making contracts with other big companies as their customers? Doesn’t seem like they could afford to just “let many fail” as they could lose the customer’s trust.
• thawaya3113 4y ago
  One of the big differences between a startup and a big company is that big companies have to make decisions about what to build. For a smaller company that decisions is already made. It’s the reason for the existence of the smaller company. And the cost of making the wrong decision can be extremely high and it can be hard to both identify that it is the wrong decision and to reverse it. With smaller companies if they make the wrong decision they will simply cease to exist, but in a larger company some other product (the one that made the company large in the first place) will cover for it. This isn’t to excuse inefficient practices, but the idea that 100% efficiency (as defined by coding 100% of the time) or even a very high coding throughput is an unmitigated good is not really valid.
• DantesKite 4y ago
  What a great writer. He has a bunch of other insightful essays I really enjoy too. Thanks for the post.
• darod 4y ago
  programmers think their job is to write code, but their job is to implement solutions. sometimes those solutions involve pushing back and asking the customer to think about their workflow a different way, sometimes those solutions involve tweaking something existing or fixing a small bug, and other times those solutions require writing and fleshing out a whole new module/feature/product. the only way you know what the solution reduces the risk and provides value to your client is by communicating with them.
• randomsearch 4y ago
  I'm super sceptical of such articles. The hardest part of software development is knowing what to build, and that requires a highly skilled product manager. The latter is a full time job for even small projects with a handful of devs.
• wly_cdgr 4y ago
  He ain't wrong, in fact he's right. Being a kissless virgin he fails to appreciate the importance of UX/UI decisions. But other than that, yeah
• TheBigSalad 4y ago
  I get annoyed working with people like the author. "Make me code, don't make me think". I get that writing code is the most fun/rewarding part of the job, but it's not the actual job. Anybody can type, figuring out what to type IS the job.
• johncessna 4y ago
  After working at several large $techCompanyAcronym companies, I agree with the author's premise, but I don't agree that the time gets wasted in planning/bickering over color palettes. I also don't agree that there's a CYA culture in large companies, at least not at the front line worker level. Here are a few issues I see: A lack of achievable goals. They tend to be massive multi-year long initiatives. It's hard to feel any sort of urgency from a 2 year project. Even if it's broken into 6 month long chunks, it's hard to feel urgency given if you slip the first milestone, you've still got 1.5 years to go. Additionally, large projects suffer from analysis paralysis. I don't think this is a malicious thing, I think folks genuinely don't know what it is they need to do. It's easy to hide in a large company. Generally, the longer it takes you to be productive the longer you can do nothing before getting noticed and/or actually terminated. An 8-12 month ramp up time is average in my experience. When the company only has 20 engineers it's easy to find the ones not pulling their weight. When you have 100k engineers, it way harder, and stack rankings, and the resulting hire-to-fire, are put into place. Mandatory and optional training and non-work related events consume a lot of time. By non-work I mean things not relevant to the team's objectives. One could easily do nothing by participating in all the summits, trainings, meetings, wellness events, interviews, debriefs, design reviews, security reviews, etc.
• promhize 4y ago
• exabrial 4y ago
  > Many Most
• plaguepilled 4y ago
  I like my own space. I'm definitely introverted. But shit like this is inexcusably antisocial and I question why it was even posted. You wanna be a s00p3r lean, high-volume company with actual impact? Good luck. 'Bloat' scales with accountability. That's a bit invective of me so lets play out a scenario. Its not a real scenario - this never happens at an actual software company, because the incentives all hit each other at once and its not explicit. Its not even guaranteed to happen all at once! But this drama does illustrate the incentives, to the extent I can demonstrate a point. Please read the below as an exposition rather than a testable hypothesis. Lets say you wanna be a lean, multinational corp providing a crucial service to high paying clients. And you do it! Congrats, you, the lead dev, and a CEO who handles 'the rest' now have a strong user base, but also a lot of opportunities to be sued if your product is actually as crucial as you suggested it was and doesn't deliver. Wait. Oops, you got sued, and you were (morally) in the right too! But fined all the same. It's a big fine. 'Never again' you and the CEO say. So now you need to hire lawyers, who advise you that to protect yourself legally, you need to monitor your service and have evidence that backs up your claims beyond 'we designed it to do that'. So now you have analysts! You are monitoring for uptime. For security. For correctness. Et cetera. Now you have an analyst team and a legal team on top of dev. But eventually your staff base grows. At some stage, payroll gets out of hand. An accounting division happens. Accounting has many jobs. One such job CAN be to lower expenditure. Accounting look at the COGs and notice that the dev team are spending money on a bunch of software but there's nothing written down as to what it does. They aren't expected to discuss their decisions with dev, so they don't. So a budget is set up by accounting based on their expectations from similar industry. Spending on tooling is among those cut. Devs complain. Work slows. The analysts complain. The CEO is annoyed at the excess spending and the slow devs. The devs are mad at how out of touch the CEO is - after all, the accountants screwed up right? Why is the dev team to blame? Things were WORKING before! Why does she instantly take the analysts word as gospel?! The CEO doesn't care about the devs or analysts to that extent though - she just wants the damn product to be shipped to spec so the company isn't sued again. But she recognises something needs to change. The natural solution is to air everyone's expectations at once. A meeting is made to make sure these show-stopping issues don't show up and a cohesive company vision can be reached. Devs have to spend time in meetings to help accounting, analytics, legal, and now marketing (since growth has slowed) not tread on their feet, and additionally prevent dev from treading on their feet. Dev team is mad. Not only are they losing coding time, but now they feel bossed around by other departments. They were doing so much more before these other BLASTED LEECHES came in and spoilt everything. Something something 'I could do it better' something something. Cue 30 replicas of this article, complaining about Working With Other People. If you're lucky, there might even be a touch of Ayn Rand laced in. Or Marx! Truly a lottery of philosophy. Eventually some devs break off and start their own schtick, and make a decent living for a while - maybe even for a lifetime, if the project is well scoped and managed! But the less cautious startups? Well, if they don't deliver... What was my point, aside from apparently being a hypocrite who can write edgy scenarios but is mad about reading them? What i am trying to argue is that the other departments are there for an explicitly profit-generating or loss-mitigating reasons. And more than that: I'm saying this should be fairly obvious and that the dialogue needs to move on from this point. More explicitly: I can understand working for a smaller company and enjoy the environment, but the constant whinging about megacorps being slow for devs and highly specialised/myopic is lazy thinking. Of COURSE they're slow. Of COURSE there's lots of documentation and meetings. You get paid a secure and comparatively higher wage for those inconveniences.
• SassyGrapefruit 4y ago
  It's not a charity. Spoilers your company is making money hand over fist. Many company's boast a $600,000 or more revenue per employee figure. In many cases you are there just for insurance. I employ more people than I need on purpose because someone might up and leave at any moment and I have to keep operations going
• commandlinefan 4y ago
  All software sucks because deadline >>> functionality/usablity/accuracy. No matter how hard management insists that this isn't the case. In fact, the more they insist that it isn't the case, the more you can be sure that it is.
• bradlys 4y ago
  I have been in a company that is similar to one of these but the codebase was massive and very problematic - a good reason for why it was hard to get things done. I think many folks here think if you work for FAANG or similar - it’s all cushy and you’re sitting on fat stacks but it just isn’t. You’ll get on a PIP real fast because you didn’t have impact - something which was out of your control because your boss assigned you a low impact feature. You’ll be kicked out within 1-2 years and back to the grind - meanwhile stressed and possibly underpaid because no refreshers and no salary bump. Again - it sounds nice in some ways but it’s a mostly brutally toxic environment and the bar to get hired is exceptionally high. If you’re getting repeatedly hired at FAANG and crew - you’re in the top 1-5% or so and it’s a very competitive bracket to stay in. Seen many go in and never be able to get back in…
• mc4ndr3 4y ago
  Third week into a role. Managers too busy to meet. One reports that we have no product owner, no audience, and no requirements. The other demands a confident promise to deliver the app by Q3. I recommend trimming the "MVP" to focus on just one, concrete user need, so that we have a prototype to deliver. Manager: No, just stub 99% of the REST contract and get it to prod. With each new software role, I feel I am somehow moving backwards compared to the relatively well positioned earlier roles.
  • phendrenad2 4y ago
    I feel this too. At an earlier role we had a well-architected PHP codebase that we were throwing away and replacing with graphql, scala, and angular. I was a junior dev so they threw me into fixing the "unimportant" legacy PHP system (which just so happened to be the thing making money for the company) instead of the shiny new rewrite. Never been happier in my life.
• AtNightWeCode 4y ago
  I agree in general. But the business is not a joke. It is a farce. Why have one time reporting system when you can have two or three? Why not also add some burndown charts to that so you must report every hour left of that ticket? Why not add an additional spreadsheet with the same info while you’re at it to get a “holistic view”? Make it two or three different spreadsheets btw so you can separate progress from work hours and gummy bears. Cause abstractions are important CS. “Gummy bears” is of course named different in each project. Remember to not mix up the gummy bears with mentos and the skittles. Some random management person will get insulted otherwise. Then the boss tells you to only work on the highest prioritized tickets. 2 minutes later the same boss mails you a side-quest that takes a day. Then the same boss asks why you have not only worked on the highest prioritized ticket. Then you show the boss 5 tickets and ask: What is the highest prioritized ticket? The boss replies: They are all the highest prioritized. Then you start to work on one ticket and the boss asks about the progress on another ticket 2 hours later. Then the boss calls you into a meeting. The meeting is set for just 20 minutes but you quickly realize that there are a lot of people in the meeting. The meeting is about some design that nobody was prepared for, so everybody must read up and improvise. 2 hours later it is decided to apply the same kerning on each heading. What the problem was or what the solution solves nobody knows. Now you get an encouraging email about what success that meeting was. But the day before some marketing person without prior notice or permission managed to do a fundamental configuration change leaving the system offline. You fixed the problem and saved the company tens of thousands of dollars even though it was outside agreed work hours. Then you get criticized by the boss because “the system is supposed to work”. And this just repeats over and over.
• phendrenad2 4y ago
  A single developer, armed with a correct and final specification, can build software far faster than a team. However, specifications are constantly changing, and are never complete, so the number of developers you need becomes infinite. FAANG have deep pockets, so they can push their efficiency from 99% to 99.9% by hiring another ten thousand programmers.
• _8j50 4y ago
  I work in infosec and I have seen this problem quite a bit but not at every company. An advice I received early on was "better to ask forgiveness than permission". So what I do once in a while is, if there is a major problem and the bureaucrats want to strangle it or play games like this, I just quietly do all the work and say "he, look! It's done!" Some will get a bit upset and inevitably my done work takes months to get reviewed and discussed before being implemented with no change. It is not good for scoring political points but shit gets done. In normal IT or sofware dev, this just means delayed projects. In security it means reduced security posture. Bad guys are not taking months and years in meetings when they attack us. It in itself is a security risk and what I do to work around such b.s. in my opinion is remediating that risk. But regardless of this, bureaucrats will still continually tear down and the build backup. Migrations the proof of concept meetings and demos. It is very hard to communicate with management that in infosec, you need to be agile and stable at the same time. Agile when responding to threats but stable in your tooling and people so you can develop maturity. I too like job security and all that but damn it! I would feel so shitty if we get pwned and all we have is excuses.
  • bozobuttz 4y ago
    I work in a devops role, and I also have the flexibility to work on fixing things that management does not deem a priority, typically when I get bored with my assigned tasks. I am much more motivated when things actually get done vs. revisiting the same problem over and over.
• stosto88 4y ago
• t_mann 4y ago
  Wasn't Agile meant to address exactly the inanity of meetings described here? Interesting that the author doesn't mention it. But I guess the thirst of middle managers in large corporations for Gantt charts just can't be quenched.
• tored 4y ago
  One unfortunately thing is that the industry in general struggles with incrementally improve functionality within a product over time, this goes for product managers, project manager, software developers etc. This is why everyone wants to make every decision up front, before you have enough knowledge about what you are building, with endless meetings instead of pushing it out and learn that way. Software developers doesn't like it because that could mean large rewrites because of ripple effects. Product owners fears that there won't be second chance to do things, thus try to cram in as much as possible early on. Project managers fears it is going to be more expensive to revisit functionality instead of doing it once.