23 ms·

> I have come to a realization that I don't really enjoy Software Engineering(& the processes that it comes with) but I do love programming & solving problems.

> I have come to a realization that I don't really enjoy Software Engineering(& the processes that it comes with) but I do love programming & solving problems. I can almost guarantee that you’re just at the wrong company. Some software companies can turn even the simplest tasks into a grueling series of processes, endless meetings, and joint work across a big number of “stakeholders”. These companies will take the joy and productivity out of programming and replace it with a series of rituals and set of language that people use to go through the motions every week so they can collect paychecks. Start interviewing around. Talk to your network. Find a company that values programming and real productivity but discourages unnecessary meetings and process. You will be much happier. There is no escaping the fact that you’ll have to work on legacy code, document your work, and meet with people some times. However, it doesn’t have to be a miserable process-filled slog.

kraig911 4y ago
1000x times this. It's a weird thing our profession. There's a horrible but apt (misogynistic even) saying. Happily married men are happy husbands - Unhappily married men are great philosophers. I really feel agile has killed the happiness of our industry because it's met with a lot of back and forth, meetings, rituals, and meta-work and not actual productivity (If agile is done well though it can be amazing but that's another topic to me)
- massinstall 4y ago
  Why is this saying misogynistic? Because it’s a statement about men or because of the implied possibility they could be unhappy in their marriage? Also, why is it horrible? It appears this world has become manically trigger-happy to label something as -ist or -istic, when it contains even only a hint of something someone could possibly understand the wrong way. It would be curious to examine in a psychological study if this reinforced behavior has developed more due to a subtle social reward system for the “labelers”, or due to a punishment system for the “non-labelers”.
  - schrodinger 4y ago
    There's a slight implication because it only covers men that women are the source of unhappiness (e.g. the nagging wife trope), but I agree it's trivial and likely unintentional. Agree with sibling, just as applicable as "happy married people are happy partners, unhappily married people are great philosophers".
    - xwdv 4y ago
      [flagged]
      - daveguy 4y ago
        Not being a dipshit is not the same thing as "bending to people's demands."
        LAC-Tech 4y ago
        I wish I had the confidence in life to genuinely think anyone who thought or spoke differently to me was just a dipshit.
        wpietri 4y ago
        That's not what he said, and I doubt it's what he meant. Many people who disagree with me are not dipshits, but the ones who are seem to take positive joy in being disagreeable.
      - elil17 4y ago
        >most people stuck in unhappy marriages are men That is wildly untrue. The research on whether men or women are more satisfied in their marriages shows that they have about the same levels of satisfaction. For example: https://onlinelibrary.wiley.com/doi/10.1111/jomf.12077 https://onlinelibrary.wiley.com/doi/10.1111/jomf.12077 Not really sure why the demographics of philosophers effects the impact of the statement. Most philosophers are white, would it have been more impactful if the statement had brought race into it?
- Beltalowda 4y ago
  You can just replace "men" with "people" and it still works.
- pydry 4y ago
  >I really feel agile has killed the happiness of our industry because it's met with a lot of back and forth, meetings, rituals, and meta-work and not actual productivity (If agile is done well though it can be amazing but that's another topic to me) All that stuff you hate isnt unique to software. It's just capitalism.
  - mangosteenjuice 4y ago
    It's not just capitalism. Bloated management and wasteful processes are problems under feudalism and communism too.
    - jpatt 4y ago
      If anything, the modern management structure more closely resembles a mini-communist state than a capitalist system. Each department's revenue goes into a shared pool, which is distributed amongst the company in annual planning cycles by an unelected board of representatives. Who gets what is as much a function of meritocratic principles like department revenue as it is of who happens to have senior leadership's ear that year (how many times have executives been convinced X is the future, we need more X, with no concrete performance to back that up?). There are some larger, more sophisticated companies that break this mold, but more the exception than the rule, I think.
      - carom 4y ago
        I have been saying this. Large corporations are command economies! There is a ton of bureaucracy too.
  - kraig911 4y ago
    Before I was in this industry most other things aren't ritualistic in their delivery. In retail, in healthcare, in hospitality, in television - it was very much quality/event driven. A thing was done it can't continuously improved upon. Software (at least relative to me) is like working on a dish as a chef that is never complete. A patient that never is healed etc. It's because so much about ritualistic definition of the task over and over. In mission critical scenarios I do feel waterfall is better. Agile is something where a small team can actually make something over time, lots of time but it's become a thing where meetings (and their number) are measured as part of the success of a project. Not the actual delivery.
- awill88 4y ago
  Feel like I would’ve said something like this at the beginning of my career.. you’re gonna go thru it, you’ll see. None of what you’re saying makes a lick of sense.
- mpweiher 4y ago
  > agile has killed the happiness...meetings...rituals...meta-work...not actual productivity. All of that isn't actual agile. It's Fauxgile and has nothing to do with what agile is about, which is about removing impediments to productivity, removing meetings (why were there standups? Because they shouldn't exist in the first place, and if you absolutely positively can't avoid them then at least make them as short as possible by making everyone as uncomfortable as they should be) and laser-focusing on actual productivity. > (If agile is done well though it can be amazing but that's another topic to me) Yes. I would phrase it as: if agile is actually done.
  - mindcrime 4y ago
    Can't upvote this enough times. Time and time again you see this: people say "I hate agile because of X, Y and Z" where X, Y, and Z - at best - are orthogonal to the idea of Agile, and at worst (and perhaps even "ordinarily") are complete anathema to the spirit of Agile. Sorry, but anybody who thinks Agile is about velocity, story points, planning poker, standups, retrospectives, backlog grooming, etc. has been sold a bill of goods. Now that's not to say that those things don't have (some) value. But they aren't "the thing" about Agile. Not even close.
    - peteradio 4y ago
      But if you are joining an Agile shop what do you get on average?
      - mpweiher 4y ago
        Fauxgile.
        roundandround 4y ago
        And every time communism meets the real world we call the required modifications state capitalism.
        4y ago
- onehair 4y ago
  Would the opposite of what you describe here be : program all the time and ship things as fast as possible? I've found that in many cases, that generally makes return on investment hard to keep track of, and I think that most companies want profit. Balance is the key though and balancing what you describe as bad with fast shipping, I think is the best of both worlds
- highwaylights 4y ago
  I’m with you right up to “if agile is done well”. It’s just a buzzword for practices that people would be doing better otherwise without all the bureaucracy. Pretty sure one of the original authors of the manifesto declared it dead too, but I’m not going to google it because honestly the agile manifesto is not a religious text to me and I think the whole industry grew out of a single fairly common sense idea that got utterly co-opted by snake oil salesmen. Like DevOps.
  - mindcrime 4y ago
    It's a fair point. The whole DevOps thing is so ludicrous. I've seen companies that don't just have a "DevOps team" (which is absurd in and of itself) but multiple DevOps Teams, and I'm pretty sure there are some DevOps Teams that have embedded DevOps Teams that in turn have more embedded DevOps Teams. And all of these people are completely gated off from interacting with the people actually building applications by a byzantine process involving ServiceNow tickets, MS Teams messages, eldritch incantations to Elder gods, ritual sacrifices, and the phrase "The goat doesn't need to be very big, but it does need to be alive."
    - Aeolun 4y ago
      I think you are underestimating the DevOps teams. Cthulhu is a lot easier to please.
    - garethrowlands 4y ago
      DevOps merges Dev and Ops. It is not an extra team.
      - mindcrime 4y ago
        Sure, you and I know that. But try telling that to all of these companies out here standing up a "devops team" left and right!
- gymbeaux 4y ago
  I like Agile, but I hate “Agile” (that is, how Agile is interpreted and implemented by the management of the companies I’ve worked at). I worked at Allstate years ago, and was on the team that piloted Agile (Scrum). It was done by the book, and I thought it was awesome. We had a quick scrum meeting each day, and the retros and plannings were only on Wednesdays. Sprints ended on Wednesdays. Most companies have their sprints start or end on Monday or Friday, but those are COMMON days for people to take PTO, nevermind national holidays are usually on those days. That was the first company i worked at which was Agile, and I haven’t been to a company since that did it as effectively. Ironic that it was Allstate. Just about everything else about the company absolutely sucked.
  - rerdavies 4y ago
    Wednesday to Wednesday is brilliant! Thanks.
- wpietri 4y ago
  > agile has killed the happiness of our industry I don't think you're wrong, but I should point out that Agile started out as a rebellion against "meetings, rituals, and meta-work and not actual productivity". As somebody who got involved in one of the Agile tributaries before the term "Agile" was coined, I'd say the actual problem is older and deeper. I look forward to another rebellion, but would-be revolutionaries should make sure they don't fall into the same trap, or you too will see your new terms and bold ideas corrupted to the point of meaninglessness.
  - ianmcgowan 4y ago
    It seems that this generation's revolutionaries are always the next generation's reactionaries..
    - wpietri 4y ago
      In this case, not so much. Most of the early Agile people I've had the chance to talk with are a bit horrified by what it's become.
      - fijiaarone 4y ago
        Isn’t that the definition of reactionary?
        wpietri 4y ago
        No? Reactionaries want to return to the previous status quo. The early Agile people I know instead would like to see a revolution actually happen.
      - 59nadir 4y ago
        Indeed. Most of the commentary I've seen from people who were around is that scrum isn't agile but just an impotent compromise made by people who thought business could never actually handle an actually agile (as in flexible) work methodology. I think they're mostly right; Scrum really isn't very flexible. On top of that, like most popular languages and technologies it isn't really good enough for people who care, but it's good enough for people who don't and also happens to please "biz" people.
- misja111 4y ago
  > I really feel agile has killed the happiness of our industry because it's met with a lot of back and forth, meetings, rituals, and meta-work and not actual productivity Agile was created to beat exactly those things that you are mentioning. Then Agile became big, enterprise became aware of it and smothered it with their rituals, processes and bureaucracy. And now we're back where we started again.
  - t43562 4y ago
    At higher management levels people are trying to "achieve" some goals and of course "agile" means that you are constantly evaluating what to achieve and discarding some of it while perhaps adding new things. There's less agility higher up because I think it takes too long for any of those goals to be proven stupid (or proven smart) so it's waterfall ontop and agile underneath and that's obviously a clash.
- GrabbinD33ze69 4y ago
  ITT: we observe the sheer amount of ignorance & naivety that rears its ugly head when stemlords attempt to discuss any sort of social issue / concept. It's crazy how one would interpret you pointing out the slight misogynistic undertones of the phrase you quoted as "making things political". I'm not going to mention any popular figure by name as that would be quite inflammatory, but it's not wonder certain individuals can disguise terrible opinions as the "facts & logic" based take & especially dupe men who are in a stem field. Really reinforces the stereotype of male engineers/scientists who think their field's knowledge somehow universally applies to the less "technical" sciences such as social sciences.
  - deleted 4y ago
    [deleted]
- tjrDL6MjB2Zwwa 4y ago
  > Happily married men are happy husbands - Unhappily married men are great philosophers. I'm not sure I understand what this means, can someone clarify for me?
  - fijiaarone 4y ago
    You’ll have to get married and grow old to understand.
    - tjrDL6MjB2Zwwa 4y ago
      [flagged]
  - rerdavies 4y ago
    Philosophy is for unhappy people.
    - tjrDL6MjB2Zwwa 4y ago
      [flagged]
  - alexvoda 4y ago
    I have detailed that and linked an even more comprehensive explanation in this sibling (cousin?) comment: https://news.ycombinator.com/item?id=34380697 https://news.ycombinator.com/item?id=34380697
    - tjrDL6MjB2Zwwa 4y ago
      [flagged]
  - alexvoda 4y ago
    My point was that the saying itself is wrong and a bad meme (the ethics of it were secondary to my argument) and I linked to where it originated to show that it wasn't even a thing in the first place. Explaining the meaning of a bad meme is not interesting but if you are still asking what it is supposed to mean then here goes: The first half is obvious because it is a tautology. It states that "An X is an X." The second half implies that unhappiness pushes one to become a philosopher because they start thinking about how they became unhappy. Why? Who knows. Most unhappy people do not become philosophers, but some might. Also, not all philosophers are unhappy. Also, gender and being married or not have nothing to do with becoming a philosopher. You are correct that it's confusing why the implication should go without saying. It's because it doesn't. It's a simplified rewording and further generalization of a misattributed misquote meme that is itself a generalization and mischaracterization of a dialogue line of a philosopher describing his own situation and his own choices. As for why happiness is less productive then unhappiness, there is this gem of an explainer: https://www.youtube.com/watch?v=yWkq7btSQvs https://www.youtube.com/watch?v=yWkq7btSQvs
- jacobr1 4y ago
  > I really feel agile has killed the happiness of our industry Waterfall had its own endless set of meetings and downsides. I'm not sure agile changed that at all in the large, regardless of how "well" agile was implemented. Some teams did have project management that "shielded" teams, but that can happen under agile too, depending upon how it is structured.
  - t43562 4y ago
    I've enjoyed it working well. It was much better than being project managed. A great deal of the time it let us toss out stupid requirements - they just sat at the bottom of the infinite backlog because they weren't needed yet.
- jasmer 4y ago
  It's 'gendered', not 'misogynist'.
- necovek 4y ago
  It's actually quite funny because "agile" basically means (in English) "quick to react", which should imply not much process at all (and when properly implemented, usually is).
MuffinFlavored 4y ago
> I can almost guarantee that you’re just at the wrong company. Even if this is true (which it most likely is), there's no guarantee the company you move to (in your quest of finding "the right company") won't either a) also be the wrong company again right off the bat or b) become the wrong company again. I've kind of just given up. I've accepted I'm basically a "technical plumber". Take data from this system/vendor in this format, convert it to another, make low six figures, have benefits, try to focus on life outside of work.
- digitalsushi 4y ago
  Three years ago I was stuck at a huge fortune 100 with all the ceremonies, business language, and paycheck collectors. I started to shop around. I found an amazing place, a company that was a software company not not a company that happened to write some software. The interviews went amazing, everything was Star Trek utopian future amazing, it was like the fantasy I had about where I wanted to work had manifested. I got a job offer, and took it immediately. The first day of work, no one on my team was there to let me in, so I hung out in the lobby for several hours waiting for anyone brave enough to get me to the badge people so I could open the door on my own. By five months in, I'd not had a manager check in yet, no one on the team would talk to me, and I realized I was a professional bench warmer. I'd been bamboozled, body-snatched from my boring, process-jammed, low-progress IT job. Fortunately the fortune 100 took me back. I hadn't burned any bridges on my way out, and my seat was still warm. My cube was still there, my gear all waiting for me to just log right back in 6 months later like I was simply on a long break. Three years later I'm still here. I'm terrified to go looking again cause I can't have my heart broken twice so soon. I have no idea how to interview well enough to detect a trap. I think my age has a lot to do with it (I'm in my mid 40s and I average about 7 years per company so I don't experiment a lot with this). I think that your strategy is the same as mine and that you should be rewarded for sticking with it, because there's success in it even if you're not constantly being entertained by solving the big interesting problems. Running a little personal infrastructure to learn the next big platform/language/thing is always a great hobby for people who can do a little more work outside of work, and just having interests that don't earn you anything at all are the most rewarding for finding brief moments of happiness.
soneca 4y ago
I agree and I would suggest trying small companies or very early stage startups (with less than 10 Software developers). You get to program a lo, but not all goods though. A lot of context change and you have to also think about product and design, so it’s not just programming. Also the risk of the company not existing in a year. But, for me, it’s perfect.
kodah 4y ago
Agreed, this sounds like OP is in the wrong job. To me, there are two types of companies as an engineer. There are companies that like engineers to focus solely on product. This is the kind of company you'll hear "don't reinvent the wheel" a lot at because their understanding of their core skills probably doesn't branch that deep into engineering. Then there's companies where engineering is core to the product. Some folks hate these kinds of companies, but I tend to enjoy them because even the niche networking stack is related to product delivery somehow. Product-focused companies also, in my experience, tend to put a lot more emphasis on ritual precision. Agile isn't just a means of organizing, it becomes the way you get things done. These companies also tend to have some culty vibes to them, but again, could just be my experience. At engineering focused companies I've "done Agile" but the emphasis was mainly on giving me tools, systems, and incentives to self-organize more than the rituals themselves. These kind of companies are actually where I learned to love testing a lot more than I used to, but that was because someone took the time to shape how I wrote code so that it was easy to test.
- x0x0 4y ago
  It could also be the wrong tools. eg I like having tests, and I like writing them, because they make my life better. But the contrast between the effort level to write tests in ruby or python vs go... I hate go, I hate the lack of good mock support, and I dislike writing tests at work because I hate go.
lloydatkinson 4y ago
I concur, I even wrote this down as I found it therapeutic. https://www.lloydatkinson.net/posts/2022/my-thoughts-on-what-i-want-to-do-as-a-software-developer/ https://www.lloydatkinson.net/posts/2022/my-thoughts-on-what...
stitched2gethr 4y ago
Seconded. And might I suggest a smaller company. Smaller companies (like startups) are about about solving the problems at hand quickly. As companies grow there is a larger risk that any one mistake can lose the company money, which will generally continue to flow if they do nothing, and so they intentionally put in a lot of road blocks.
karaterobot 4y ago
I dunno, I think OP may be right. I was in the same boat: I thought I hated programming, then one day I realized I just hated the industry wrapper around it. I recognize some of that process stuff can be valuable, but it's hard to disentangle the good stuff from the trash. Much of it is cargo cult, article-driven thinking that does nobody any good. A few years ago I switched to design, and now I just program in my spare time for fun. And it is fun when you do it right.
jstx1 4y ago
Not enough process can be a pain too. "Just do this for us" without specific requirements, and then the thing you've built is never good enough and needs to be continually refined anyway or it's never used. Those environments are also soul crushing, just in a different way from the ones with too much process.
- snowstormsun 4y ago
  assuming the process actually includes proper specification of work
- Kamq 4y ago
  You're assuming they're mutually exclusive. I've had all of the ceremonies and no AC on plenty of tickets.
- Aeolun 4y ago
  I consider “Getting the requirements to be versioned on Confluence instead of with a large sequence of excel files” to be one of my big achievements. And I hate Confluence with a passion.
nouveaux 4y ago
This 1000x. For a larger project, I asked and got approval for a POC. When I submitted the POC with feature flag for review, I was told by the same management that it wasn't "production worthy". Never burned out faster in my 20+ year career.
LegitShady 4y ago
sometimes its not the wrong company but just the wrong team or even individual coworkers (I guess if you're in a company that has multiple teams). We had a new hire join a few years ago and every time they had a work task that they hadn't done before they'd make multiple meetings about their particular part of it, asking for advice in meetings instead of informal conversation, asking others to fill in documentation etc that might have been reasonable once or twice but essentially created a work by committee approach...to their work. It was exhausting and I let my manager know I was going to start declining their meetings semi regularly. When people started declining the volume of such requests and tasks suddenly dropped. But depending on how intractable your team or org, is, finding a new job may be easier.
Trasmatta 4y ago
What are these unicorn companies? I've worked at 7 companies (and interviewed at many more) and never seen anything close to this mythical "company that values programming and real productivity". I feel like they must be exceptionally rare.
- 411111111111111 4y ago
  The term unicorn in this context makes it hard to understand what you're asking, as unicorn companies are usually defined to be corporations with i believe a billion in revenue. This often comes with the usual downsides. Smallish companies often leave a lot more freedom for their developers, but you'll most likely also be missing a lot of things you've gotten used to (highly automated CI/CD, teams "responsible" for each part of the system etc)
  - at_compile_time 4y ago
    They're referring to the mythical animal, using a metaphor to express that such a company is mythical or non-existent. Coincidentally, this is same metaphor that the person who coined the term "unicorn company" was using. Given that private companies with over $1B in revenue actually exist while examples of "[companies] that values programming and real productivity" are yet to be forthcoming, the parent post is using the metaphor correctly and the finance world is not.
- ss108 4y ago
  How diverse have the companies you've worked at been in terms of size, etc? As a perhaps incomplete or shoddy heuristic, smaller startups tend to focus on productivity and moving fast.
- kasey_junk 4y ago
  I’ve worked at about 10 companies and half of them didn’t have the soul sucking processes (though all of them did have process). The correlation I see is big companies have processes that kill productivity, though I did work for a big company that was able to avoid it for a long time (new leadership did end up killing productivity right before I left). And for what it’s worth there was no correlation with “agile”. I’ve seen good and bad agile.
yellowapple 4y ago
> I can almost guarantee that you’re just at the wrong company. The trick is finding a company that's not wrong. Early-stage startups typically qualify, but they're also typically short-lived; they usually either go under or else grow into the same sort of "wrong company" one's trying to avoid. A small business that's been around awhile, with a stable customer base and no ambitions for growth, is probably ideal - but good luck getting such a company to hire you. You might have better luck picking up multiple such companies as an independent consultant. A different ideal (or so I've found) would be a company that's large but dysfunctional, or to be an "analyst" or somesuch in a department that's sufficiently large and autonomous to get away with having "shadow IT" (and a lax enough corporate IT department to not interfere).
davidw 4y ago
I think the real "unicorns" are * Small/medium size companies where you recognize most everyone even if you don't work with them. There are enough people so you don't have to do things you're not qualified for like in the very early days of a startup. * Steady growth, but not crazy, venture fueled moonshots. * Selling something that earns enough money to grow the business in a fairly organic way. I worked in a place like that once and loved it, and did some of my best work there. I wasn't anxious that it would implode like a startup, and there wasn't much bureaucracy.
- itake 4y ago
  I’ve worked at 3-4 small companies (less than 30 employees) and I’ve never been happy. There is always 1 person that makes my life miserable (constantly rejecting my ideas, ego is larger than their experience level, etc). I’ve worked at a 100, and two 1,000 engineer count companies and I never met any “coding princesses” in those roles. I think part of the problem that triggers this is in small companies, one engineer codes, a significant portion of the code base and has a strict vision in their mind about how that code should be structured. When new employees come in to bring new ideas, they become personally offended that their baby is no longer their baby. At large companies no one feels like they own 100% of the code, and each change is very collaborative.
  - electrondood 4y ago
    200-400 is the sweet spot, I've found.
  - davidw 4y ago
    Yeah I could see that. The place in question where I worked was developing some new products, so we didn't have that kind of situation where someone was gatekeeping or otherwise being unpleasant.
  - slaymaker1907 4y ago
    Oh, I've definitely met princesses at large companies, though you are spot on about the ownership issues. The problem really isn't the size of the company but how siloed the code is.
0xdeadbeefbabe 4y ago
> I can almost guarantee that you’re just at the wrong company. I can almost guarantee your company needs less of the wrong people. You need them to leave. So, ahem, talk to your network.
jensensbutton 4y ago
> Find a company that values programming and real productivity What's an example of a company that values "programming" over the business?
- gumby 4y ago
  A company that values programming over its business won't stay around long (see the recent front page submission called something like "your stack is not your product"). Sales is what covers payroll. However a company that values programming over managing will prosper more than a company that values managing more than programming. Just enough management that everybody knows they're working on the right thing is best for all (including the managers). Process for its own sake (I'm looking particularly at cargo-culting "agile" astronauts) sucks the life out of everybody involved.
- anotheracctfo 4y ago
  Valve. They're kind of dysfunctional from what I hear.
- jabedude 4y ago
  Isn't google the canonical example?
  - jensensbutton 4y ago
    I've been a manager at Google. It is not the canonical example
onehair 4y ago
I dislike working just as a "software engineer" in a team where my part in decision making on the product progression isn't very significant. I like programming and tinkering with everything in the computer science domain because it's so very thrilling and rewarding.
ok_dad 4y ago
I am here to say that both "too much" and "too little" process are shitty. I have been at companies with too much process (medical devices) and companies with WAY to little process, and both places are an absolute nightmare. What you want is a process that ensures features are spec'ed out properly, testing is performed, deployment is smooth, and etc., with a lot less or zero of the "put your hours into the Jira ticket" type bullshit.
- wpietri 4y ago
  Tastes differ, as do circumstances, but the last place I want to work is one where things are spec'd out "properly". For me one of the great sources of joy in making software is jointly discovering needs by exploring the problem space. I've done whole companies with nothing more than index cards, napkin-quality sketches, and very close team relationships. I love it.
  - ok_dad 4y ago
    That's fine until half or more of the team moves on, then you have a spaghetti mess that newcomers have to theorize about and clean up.
    - wpietri 4y ago
      I'm talking about product design, not technical design. But I don't think specifications help in the long term there, either. I think the way you get designs that are understood by both old-timers and newcomers is continuous improvement of the code through refactoring and cleanup.
      - ok_dad 4y ago
        > I'm talking about product design, not technical design. Even worse!
        wpietri 4y ago
        Ok? I'm telling you I have done it and it works well. If all you want to do is squawk about it, I guess I'll make my exit here.
flashgordon 4y ago
"wrong companies" is it. Perhaps it is love software engineering AND coding but hate big software companies? Also with "some software companies can turn even the simplest..." You may have forgotten to add "and add metrics to these rituals as performance goals"!
jxramos 4y ago
I forget what job it was I was interviewing for but I remember being stunned at the open lack of process they had in place for trying to bother unifying all these teams to be on the same platform framework etc and instead deliberately let sub teams work with tooling that worked for them and didn't create a lot of overhead trying to coordinate and sync and share a common codebase. Every place prior to that day I had only heard of people going for long stretches to impose a company wide uniformity in tooling. All the costs associated with getting everyone on the same page was always taken as a worthy cost to pay and that future date in the promise land would have made it all worth it. The folks in this other company just flat out said not worth it, just get your stuff done, ideal development scenarios and perfect harmony and alignment have too much hidden costs to bother with. It's naturally a pro and con scenario but it was pretty refreshing to hear of folks so unconstrained by this self imposed constraint every other shop had imposed on themselves.
- hn_user2 4y ago
  I have seen two extremes of this. The one side is forced conformity, and the other side was complete chaos. To the point where each project was written in its own language. Imagine changing teams to help on a project and step 1 is to learn a new language and deploy methods. I feel like there is a golden middle where the team has decided on maybe 3 languages, one typed, one scripted, one cutting edge. And a few different deploy scenarios, and you can pick amongst them.
- bennyelv 4y ago
  I work at a company that's trying to come out of the other side of this kind of approach. Let me tell you, it might feel good while you're doing it but in 5 years time it will be a hot mess of unmaintainable garbage! There are hidden costs in trying to align as you go, but there are potentially company ending costs in not. You're right that there is no promised land, but the quest to reach it prevents you regressing into hell.
deleted 4y ago
[deleted]
goodpoint 4y ago
> Some software companies can turn even the simplest tasks into a grueling series of processes, endless meetings You mean 95% of companies.
xyst 4y ago
> Some software companies can turn even the simplest tasks into a grueling series of processes, endless meetings, and joint work across a big number of “stakeholders”. These companies will take the joy and productivity out of programming and replace it with a series of rituals and set of language that people use to go through the motions every week so they can collect paychecks. god - this is so true at my last company. Any attempts to decrease meetings, remove unnecessary process are met with heavy resistance. Getting shit done was nearly impossible. People had no responsibility for their work. Only wanted "stories" and "subtasks" assigned to them. Doesn't matter if the story was trash/useless/no-op, they just wanted it to pump their numbers because the quarter is ending. I shouldn't have tried so hard to make changes. They probably ended up getting reverted by the next person or manager. Pro tip: if the company you joined tends to hire new people then retain them. Then fucking run. During the first "all hands" in that company, nearly 80% of people that worked in the organization were hired in the past 1 year or so. It ticked "red flags" at the time but I ignored it because honestly I needed the money at the time (just graduated college)
- __MatrixMan__ 4y ago
  I'm confused. Aren't all companies that got a round of funding ~1 yr ago going to have a large cohort of <1 yr tenure employees? What connects this to death-by-process?
  - ornornor 4y ago
    High churn company. Grind them out, throw them away when they’re not performing anymore, and replace them with a new batch of fresh meat to wear down. Standard playbook for an alarming number of (VC funded) companies.
casey2 4y ago
These processes exist for a reason, even if nobody knows what it is. Over time companies that did these things survived, maybe nowadays it is vestigial, but the burden of proof is on new successful companies that don't have these practices.
- mobiuscog 4y ago
  I think it's more marketing and profiteering based on correlation over causation. Almost every process these days is bought in by a new managerial hire, or after attending an event, where a talk or book that shows X companies that are very successful all followed the Y practice, and so 'we should too' as it's obviously the path to success. Rarely is there reflection on whether the process is working, and blame is laid at the feet of the workers. Despite many recollections and experiences retold about how processes may not work, they are silenced by the advocates of such processes who will show how successful they were (and also just happen to make their living by advocating rather than actually being on the ground).
inglor 4y ago
It might even be very different in the same company. I changed teams in my large company and the number of recurring meetings around process dropped from 8 to 0, no more daily, no sprint planning etc - we just talk about the feature then do it and we don’t need a lot of process since communication works well anyway.
datavirtue 4y ago
I love meeting with the right people, documenting my work, and working with legacy code. Especially meetings, nothing more invigorating than building something with a team. That said, as some have already mentioned, all of this is typically ruined somehow at nearly every company.
DrBazza 4y ago
> I can almost guarantee that you’re just at the wrong company. You're at the wrong company if you're unhappy regardless of the size. I've worked at a very small company which was miserable because the owner didn't have a clue and was only interested in the bottom line to the point of letting the software and the systems atrophy. I've worked at Megabank, and it was also miserable. Actually writing code probably ended up being a sum total of 3-4 hours a week. At best. Too many meetings. Absurd change control system. Crazy processes and sign off. And then there have been a few mid-sized companies - 20-200, and they've been the most fun. Get on with coding and even whilst managing a small team.

kraig911 4y ago

1000x times this. It's a weird thing our profession. There's a horrible but apt (misogynistic even) saying. Happily married men are happy husbands - Unhappily married men are great philosophers. I really feel agile has killed the happiness of our industry because it's met with a lot of back and forth, meetings, rituals, and meta-work and not actual productivity (If agile is done well though it can be amazing but that's another topic to me)

massinstall 4y ago
Why is this saying misogynistic? Because it’s a statement about men or because of the implied possibility they could be unhappy in their marriage? Also, why is it horrible? It appears this world has become manically trigger-happy to label something as -ist or -istic, when it contains even only a hint of something someone could possibly understand the wrong way. It would be curious to examine in a psychological study if this reinforced behavior has developed more due to a subtle social reward system for the “labelers”, or due to a punishment system for the “non-labelers”.
- schrodinger 4y ago
  There's a slight implication because it only covers men that women are the source of unhappiness (e.g. the nagging wife trope), but I agree it's trivial and likely unintentional. Agree with sibling, just as applicable as "happy married people are happy partners, unhappily married people are great philosophers".
  - xwdv 4y ago
    [flagged]
    - daveguy 4y ago
      Not being a dipshit is not the same thing as "bending to people's demands."
      - LAC-Tech 4y ago
        I wish I had the confidence in life to genuinely think anyone who thought or spoke differently to me was just a dipshit.
        wpietri 4y ago
        That's not what he said, and I doubt it's what he meant. Many people who disagree with me are not dipshits, but the ones who are seem to take positive joy in being disagreeable.
    - elil17 4y ago
      >most people stuck in unhappy marriages are men That is wildly untrue. The research on whether men or women are more satisfied in their marriages shows that they have about the same levels of satisfaction. For example: https://onlinelibrary.wiley.com/doi/10.1111/jomf.12077 https://onlinelibrary.wiley.com/doi/10.1111/jomf.12077 Not really sure why the demographics of philosophers effects the impact of the statement. Most philosophers are white, would it have been more impactful if the statement had brought race into it?
Beltalowda 4y ago
You can just replace "men" with "people" and it still works.
pydry 4y ago
>I really feel agile has killed the happiness of our industry because it's met with a lot of back and forth, meetings, rituals, and meta-work and not actual productivity (If agile is done well though it can be amazing but that's another topic to me) All that stuff you hate isnt unique to software. It's just capitalism.
- mangosteenjuice 4y ago
  It's not just capitalism. Bloated management and wasteful processes are problems under feudalism and communism too.
  - jpatt 4y ago
    If anything, the modern management structure more closely resembles a mini-communist state than a capitalist system. Each department's revenue goes into a shared pool, which is distributed amongst the company in annual planning cycles by an unelected board of representatives. Who gets what is as much a function of meritocratic principles like department revenue as it is of who happens to have senior leadership's ear that year (how many times have executives been convinced X is the future, we need more X, with no concrete performance to back that up?). There are some larger, more sophisticated companies that break this mold, but more the exception than the rule, I think.
    - carom 4y ago
      I have been saying this. Large corporations are command economies! There is a ton of bureaucracy too.
- kraig911 4y ago
  Before I was in this industry most other things aren't ritualistic in their delivery. In retail, in healthcare, in hospitality, in television - it was very much quality/event driven. A thing was done it can't continuously improved upon. Software (at least relative to me) is like working on a dish as a chef that is never complete. A patient that never is healed etc. It's because so much about ritualistic definition of the task over and over. In mission critical scenarios I do feel waterfall is better. Agile is something where a small team can actually make something over time, lots of time but it's become a thing where meetings (and their number) are measured as part of the success of a project. Not the actual delivery.
awill88 4y ago
Feel like I would’ve said something like this at the beginning of my career.. you’re gonna go thru it, you’ll see. None of what you’re saying makes a lick of sense.
mpweiher 4y ago
> agile has killed the happiness...meetings...rituals...meta-work...not actual productivity. All of that isn't actual agile. It's Fauxgile and has nothing to do with what agile is about, which is about removing impediments to productivity, removing meetings (why were there standups? Because they shouldn't exist in the first place, and if you absolutely positively can't avoid them then at least make them as short as possible by making everyone as uncomfortable as they should be) and laser-focusing on actual productivity. > (If agile is done well though it can be amazing but that's another topic to me) Yes. I would phrase it as: if agile is actually done.
- mindcrime 4y ago
  Can't upvote this enough times. Time and time again you see this: people say "I hate agile because of X, Y and Z" where X, Y, and Z - at best - are orthogonal to the idea of Agile, and at worst (and perhaps even "ordinarily") are complete anathema to the spirit of Agile. Sorry, but anybody who thinks Agile is about velocity, story points, planning poker, standups, retrospectives, backlog grooming, etc. has been sold a bill of goods. Now that's not to say that those things don't have (some) value. But they aren't "the thing" about Agile. Not even close.
  - peteradio 4y ago
    But if you are joining an Agile shop what do you get on average?
    - mpweiher 4y ago
      Fauxgile.
      - roundandround 4y ago
        And every time communism meets the real world we call the required modifications state capitalism.
        4y ago
onehair 4y ago
Would the opposite of what you describe here be : program all the time and ship things as fast as possible? I've found that in many cases, that generally makes return on investment hard to keep track of, and I think that most companies want profit. Balance is the key though and balancing what you describe as bad with fast shipping, I think is the best of both worlds
highwaylights 4y ago
I’m with you right up to “if agile is done well”. It’s just a buzzword for practices that people would be doing better otherwise without all the bureaucracy. Pretty sure one of the original authors of the manifesto declared it dead too, but I’m not going to google it because honestly the agile manifesto is not a religious text to me and I think the whole industry grew out of a single fairly common sense idea that got utterly co-opted by snake oil salesmen. Like DevOps.
- mindcrime 4y ago
  It's a fair point. The whole DevOps thing is so ludicrous. I've seen companies that don't just have a "DevOps team" (which is absurd in and of itself) but multiple DevOps Teams, and I'm pretty sure there are some DevOps Teams that have embedded DevOps Teams that in turn have more embedded DevOps Teams. And all of these people are completely gated off from interacting with the people actually building applications by a byzantine process involving ServiceNow tickets, MS Teams messages, eldritch incantations to Elder gods, ritual sacrifices, and the phrase "The goat doesn't need to be very big, but it does need to be alive."
  - Aeolun 4y ago
    I think you are underestimating the DevOps teams. Cthulhu is a lot easier to please.
  - garethrowlands 4y ago
    DevOps merges Dev and Ops. It is not an extra team.
    - mindcrime 4y ago
      Sure, you and I know that. But try telling that to all of these companies out here standing up a "devops team" left and right!
gymbeaux 4y ago
I like Agile, but I hate “Agile” (that is, how Agile is interpreted and implemented by the management of the companies I’ve worked at). I worked at Allstate years ago, and was on the team that piloted Agile (Scrum). It was done by the book, and I thought it was awesome. We had a quick scrum meeting each day, and the retros and plannings were only on Wednesdays. Sprints ended on Wednesdays. Most companies have their sprints start or end on Monday or Friday, but those are COMMON days for people to take PTO, nevermind national holidays are usually on those days. That was the first company i worked at which was Agile, and I haven’t been to a company since that did it as effectively. Ironic that it was Allstate. Just about everything else about the company absolutely sucked.
- rerdavies 4y ago
  Wednesday to Wednesday is brilliant! Thanks.
wpietri 4y ago
> agile has killed the happiness of our industry I don't think you're wrong, but I should point out that Agile started out as a rebellion against "meetings, rituals, and meta-work and not actual productivity". As somebody who got involved in one of the Agile tributaries before the term "Agile" was coined, I'd say the actual problem is older and deeper. I look forward to another rebellion, but would-be revolutionaries should make sure they don't fall into the same trap, or you too will see your new terms and bold ideas corrupted to the point of meaninglessness.
- ianmcgowan 4y ago
  It seems that this generation's revolutionaries are always the next generation's reactionaries..
  - wpietri 4y ago
    In this case, not so much. Most of the early Agile people I've had the chance to talk with are a bit horrified by what it's become.
    - fijiaarone 4y ago
      Isn’t that the definition of reactionary?
      - wpietri 4y ago
        No? Reactionaries want to return to the previous status quo. The early Agile people I know instead would like to see a revolution actually happen.
    - 59nadir 4y ago
      Indeed. Most of the commentary I've seen from people who were around is that scrum isn't agile but just an impotent compromise made by people who thought business could never actually handle an actually agile (as in flexible) work methodology. I think they're mostly right; Scrum really isn't very flexible. On top of that, like most popular languages and technologies it isn't really good enough for people who care, but it's good enough for people who don't and also happens to please "biz" people.
misja111 4y ago
> I really feel agile has killed the happiness of our industry because it's met with a lot of back and forth, meetings, rituals, and meta-work and not actual productivity Agile was created to beat exactly those things that you are mentioning. Then Agile became big, enterprise became aware of it and smothered it with their rituals, processes and bureaucracy. And now we're back where we started again.
- t43562 4y ago
  At higher management levels people are trying to "achieve" some goals and of course "agile" means that you are constantly evaluating what to achieve and discarding some of it while perhaps adding new things. There's less agility higher up because I think it takes too long for any of those goals to be proven stupid (or proven smart) so it's waterfall ontop and agile underneath and that's obviously a clash.
GrabbinD33ze69 4y ago
ITT: we observe the sheer amount of ignorance & naivety that rears its ugly head when stemlords attempt to discuss any sort of social issue / concept. It's crazy how one would interpret you pointing out the slight misogynistic undertones of the phrase you quoted as "making things political". I'm not going to mention any popular figure by name as that would be quite inflammatory, but it's not wonder certain individuals can disguise terrible opinions as the "facts & logic" based take & especially dupe men who are in a stem field. Really reinforces the stereotype of male engineers/scientists who think their field's knowledge somehow universally applies to the less "technical" sciences such as social sciences.
- deleted 4y ago
  [deleted]
tjrDL6MjB2Zwwa 4y ago
> Happily married men are happy husbands - Unhappily married men are great philosophers. I'm not sure I understand what this means, can someone clarify for me?
- fijiaarone 4y ago
  You’ll have to get married and grow old to understand.
  - tjrDL6MjB2Zwwa 4y ago
    [flagged]
- rerdavies 4y ago
  Philosophy is for unhappy people.
  - tjrDL6MjB2Zwwa 4y ago
    [flagged]
- alexvoda 4y ago
  I have detailed that and linked an even more comprehensive explanation in this sibling (cousin?) comment: https://news.ycombinator.com/item?id=34380697 https://news.ycombinator.com/item?id=34380697
  - tjrDL6MjB2Zwwa 4y ago
    [flagged]
- alexvoda 4y ago
  My point was that the saying itself is wrong and a bad meme (the ethics of it were secondary to my argument) and I linked to where it originated to show that it wasn't even a thing in the first place. Explaining the meaning of a bad meme is not interesting but if you are still asking what it is supposed to mean then here goes: The first half is obvious because it is a tautology. It states that "An X is an X." The second half implies that unhappiness pushes one to become a philosopher because they start thinking about how they became unhappy. Why? Who knows. Most unhappy people do not become philosophers, but some might. Also, not all philosophers are unhappy. Also, gender and being married or not have nothing to do with becoming a philosopher. You are correct that it's confusing why the implication should go without saying. It's because it doesn't. It's a simplified rewording and further generalization of a misattributed misquote meme that is itself a generalization and mischaracterization of a dialogue line of a philosopher describing his own situation and his own choices. As for why happiness is less productive then unhappiness, there is this gem of an explainer: https://www.youtube.com/watch?v=yWkq7btSQvs https://www.youtube.com/watch?v=yWkq7btSQvs
jacobr1 4y ago
> I really feel agile has killed the happiness of our industry Waterfall had its own endless set of meetings and downsides. I'm not sure agile changed that at all in the large, regardless of how "well" agile was implemented. Some teams did have project management that "shielded" teams, but that can happen under agile too, depending upon how it is structured.
- t43562 4y ago
  I've enjoyed it working well. It was much better than being project managed. A great deal of the time it let us toss out stupid requirements - they just sat at the bottom of the infinite backlog because they weren't needed yet.
jasmer 4y ago
It's 'gendered', not 'misogynist'.
necovek 4y ago
It's actually quite funny because "agile" basically means (in English) "quick to react", which should imply not much process at all (and when properly implemented, usually is).

MuffinFlavored 4y ago

> I can almost guarantee that you’re just at the wrong company. Even if this is true (which it most likely is), there's no guarantee the company you move to (in your quest of finding "the right company") won't either a) also be the wrong company again right off the bat or b) become the wrong company again. I've kind of just given up. I've accepted I'm basically a "technical plumber". Take data from this system/vendor in this format, convert it to another, make low six figures, have benefits, try to focus on life outside of work.

digitalsushi 4y ago
Three years ago I was stuck at a huge fortune 100 with all the ceremonies, business language, and paycheck collectors. I started to shop around. I found an amazing place, a company that was a software company not not a company that happened to write some software. The interviews went amazing, everything was Star Trek utopian future amazing, it was like the fantasy I had about where I wanted to work had manifested. I got a job offer, and took it immediately. The first day of work, no one on my team was there to let me in, so I hung out in the lobby for several hours waiting for anyone brave enough to get me to the badge people so I could open the door on my own. By five months in, I'd not had a manager check in yet, no one on the team would talk to me, and I realized I was a professional bench warmer. I'd been bamboozled, body-snatched from my boring, process-jammed, low-progress IT job. Fortunately the fortune 100 took me back. I hadn't burned any bridges on my way out, and my seat was still warm. My cube was still there, my gear all waiting for me to just log right back in 6 months later like I was simply on a long break. Three years later I'm still here. I'm terrified to go looking again cause I can't have my heart broken twice so soon. I have no idea how to interview well enough to detect a trap. I think my age has a lot to do with it (I'm in my mid 40s and I average about 7 years per company so I don't experiment a lot with this). I think that your strategy is the same as mine and that you should be rewarded for sticking with it, because there's success in it even if you're not constantly being entertained by solving the big interesting problems. Running a little personal infrastructure to learn the next big platform/language/thing is always a great hobby for people who can do a little more work outside of work, and just having interests that don't earn you anything at all are the most rewarding for finding brief moments of happiness.

soneca 4y ago

I agree and I would suggest trying small companies or very early stage startups (with less than 10 Software developers). You get to program a lo, but not all goods though. A lot of context change and you have to also think about product and design, so it’s not just programming. Also the risk of the company not existing in a year. But, for me, it’s perfect.

kodah 4y ago

Agreed, this sounds like OP is in the wrong job. To me, there are two types of companies as an engineer. There are companies that like engineers to focus solely on product. This is the kind of company you'll hear "don't reinvent the wheel" a lot at because their understanding of their core skills probably doesn't branch that deep into engineering. Then there's companies where engineering is core to the product. Some folks hate these kinds of companies, but I tend to enjoy them because even the niche networking stack is related to product delivery somehow. Product-focused companies also, in my experience, tend to put a lot more emphasis on ritual precision. Agile isn't just a means of organizing, it becomes the way you get things done. These companies also tend to have some culty vibes to them, but again, could just be my experience. At engineering focused companies I've "done Agile" but the emphasis was mainly on giving me tools, systems, and incentives to self-organize more than the rituals themselves. These kind of companies are actually where I learned to love testing a lot more than I used to, but that was because someone took the time to shape how I wrote code so that it was easy to test.

x0x0 4y ago
It could also be the wrong tools. eg I like having tests, and I like writing them, because they make my life better. But the contrast between the effort level to write tests in ruby or python vs go... I hate go, I hate the lack of good mock support, and I dislike writing tests at work because I hate go.

lloydatkinson 4y ago

I concur, I even wrote this down as I found it therapeutic. https://www.lloydatkinson.net/posts/2022/my-thoughts-on-what-i-want-to-do-as-a-software-developer/ https://www.lloydatkinson.net/posts/2022/my-thoughts-on-what...

stitched2gethr 4y ago

Seconded. And might I suggest a smaller company. Smaller companies (like startups) are about about solving the problems at hand quickly. As companies grow there is a larger risk that any one mistake can lose the company money, which will generally continue to flow if they do nothing, and so they intentionally put in a lot of road blocks.

karaterobot 4y ago

I dunno, I think OP may be right. I was in the same boat: I thought I hated programming, then one day I realized I just hated the industry wrapper around it. I recognize some of that process stuff can be valuable, but it's hard to disentangle the good stuff from the trash. Much of it is cargo cult, article-driven thinking that does nobody any good. A few years ago I switched to design, and now I just program in my spare time for fun. And it is fun when you do it right.

jstx1 4y ago

Not enough process can be a pain too. "Just do this for us" without specific requirements, and then the thing you've built is never good enough and needs to be continually refined anyway or it's never used. Those environments are also soul crushing, just in a different way from the ones with too much process.

snowstormsun 4y ago
assuming the process actually includes proper specification of work
Kamq 4y ago
You're assuming they're mutually exclusive. I've had all of the ceremonies and no AC on plenty of tickets.
Aeolun 4y ago
I consider “Getting the requirements to be versioned on Confluence instead of with a large sequence of excel files” to be one of my big achievements. And I hate Confluence with a passion.

nouveaux 4y ago

This 1000x. For a larger project, I asked and got approval for a POC. When I submitted the POC with feature flag for review, I was told by the same management that it wasn't "production worthy". Never burned out faster in my 20+ year career.

LegitShady 4y ago

sometimes its not the wrong company but just the wrong team or even individual coworkers (I guess if you're in a company that has multiple teams). We had a new hire join a few years ago and every time they had a work task that they hadn't done before they'd make multiple meetings about their particular part of it, asking for advice in meetings instead of informal conversation, asking others to fill in documentation etc that might have been reasonable once or twice but essentially created a work by committee approach...to their work. It was exhausting and I let my manager know I was going to start declining their meetings semi regularly. When people started declining the volume of such requests and tasks suddenly dropped. But depending on how intractable your team or org, is, finding a new job may be easier.

Trasmatta 4y ago

What are these unicorn companies? I've worked at 7 companies (and interviewed at many more) and never seen anything close to this mythical "company that values programming and real productivity". I feel like they must be exceptionally rare.

411111111111111 4y ago
The term unicorn in this context makes it hard to understand what you're asking, as unicorn companies are usually defined to be corporations with i believe a billion in revenue. This often comes with the usual downsides. Smallish companies often leave a lot more freedom for their developers, but you'll most likely also be missing a lot of things you've gotten used to (highly automated CI/CD, teams "responsible" for each part of the system etc)
- at_compile_time 4y ago
  They're referring to the mythical animal, using a metaphor to express that such a company is mythical or non-existent. Coincidentally, this is same metaphor that the person who coined the term "unicorn company" was using. Given that private companies with over $1B in revenue actually exist while examples of "[companies] that values programming and real productivity" are yet to be forthcoming, the parent post is using the metaphor correctly and the finance world is not.
ss108 4y ago
How diverse have the companies you've worked at been in terms of size, etc? As a perhaps incomplete or shoddy heuristic, smaller startups tend to focus on productivity and moving fast.
kasey_junk 4y ago
I’ve worked at about 10 companies and half of them didn’t have the soul sucking processes (though all of them did have process). The correlation I see is big companies have processes that kill productivity, though I did work for a big company that was able to avoid it for a long time (new leadership did end up killing productivity right before I left). And for what it’s worth there was no correlation with “agile”. I’ve seen good and bad agile.

yellowapple 4y ago

> I can almost guarantee that you’re just at the wrong company. The trick is finding a company that's not wrong. Early-stage startups typically qualify, but they're also typically short-lived; they usually either go under or else grow into the same sort of "wrong company" one's trying to avoid. A small business that's been around awhile, with a stable customer base and no ambitions for growth, is probably ideal - but good luck getting such a company to hire you. You might have better luck picking up multiple such companies as an independent consultant. A different ideal (or so I've found) would be a company that's large but dysfunctional, or to be an "analyst" or somesuch in a department that's sufficiently large and autonomous to get away with having "shadow IT" (and a lax enough corporate IT department to not interfere).

davidw 4y ago

I think the real "unicorns" are * Small/medium size companies where you recognize most everyone even if you don't work with them. There are enough people so you don't have to do things you're not qualified for like in the very early days of a startup. * Steady growth, but not crazy, venture fueled moonshots. * Selling something that earns enough money to grow the business in a fairly organic way. I worked in a place like that once and loved it, and did some of my best work there. I wasn't anxious that it would implode like a startup, and there wasn't much bureaucracy.

itake 4y ago
I’ve worked at 3-4 small companies (less than 30 employees) and I’ve never been happy. There is always 1 person that makes my life miserable (constantly rejecting my ideas, ego is larger than their experience level, etc). I’ve worked at a 100, and two 1,000 engineer count companies and I never met any “coding princesses” in those roles. I think part of the problem that triggers this is in small companies, one engineer codes, a significant portion of the code base and has a strict vision in their mind about how that code should be structured. When new employees come in to bring new ideas, they become personally offended that their baby is no longer their baby. At large companies no one feels like they own 100% of the code, and each change is very collaborative.
- electrondood 4y ago
  200-400 is the sweet spot, I've found.
- davidw 4y ago
  Yeah I could see that. The place in question where I worked was developing some new products, so we didn't have that kind of situation where someone was gatekeeping or otherwise being unpleasant.
- slaymaker1907 4y ago
  Oh, I've definitely met princesses at large companies, though you are spot on about the ownership issues. The problem really isn't the size of the company but how siloed the code is.

0xdeadbeefbabe 4y ago

> I can almost guarantee that you’re just at the wrong company. I can almost guarantee your company needs less of the wrong people. You need them to leave. So, ahem, talk to your network.

jensensbutton 4y ago

> Find a company that values programming and real productivity What's an example of a company that values "programming" over the business?

gumby 4y ago
A company that values programming over its business won't stay around long (see the recent front page submission called something like "your stack is not your product"). Sales is what covers payroll. However a company that values programming over managing will prosper more than a company that values managing more than programming. Just enough management that everybody knows they're working on the right thing is best for all (including the managers). Process for its own sake (I'm looking particularly at cargo-culting "agile" astronauts) sucks the life out of everybody involved.
anotheracctfo 4y ago
Valve. They're kind of dysfunctional from what I hear.
jabedude 4y ago
Isn't google the canonical example?
- jensensbutton 4y ago
  I've been a manager at Google. It is not the canonical example

onehair 4y ago

I dislike working just as a "software engineer" in a team where my part in decision making on the product progression isn't very significant. I like programming and tinkering with everything in the computer science domain because it's so very thrilling and rewarding.

ok_dad 4y ago

I am here to say that both "too much" and "too little" process are shitty. I have been at companies with too much process (medical devices) and companies with WAY to little process, and both places are an absolute nightmare. What you want is a process that ensures features are spec'ed out properly, testing is performed, deployment is smooth, and etc., with a lot less or zero of the "put your hours into the Jira ticket" type bullshit.

wpietri 4y ago
Tastes differ, as do circumstances, but the last place I want to work is one where things are spec'd out "properly". For me one of the great sources of joy in making software is jointly discovering needs by exploring the problem space. I've done whole companies with nothing more than index cards, napkin-quality sketches, and very close team relationships. I love it.
- ok_dad 4y ago
  That's fine until half or more of the team moves on, then you have a spaghetti mess that newcomers have to theorize about and clean up.
  - wpietri 4y ago
    I'm talking about product design, not technical design. But I don't think specifications help in the long term there, either. I think the way you get designs that are understood by both old-timers and newcomers is continuous improvement of the code through refactoring and cleanup.
    - ok_dad 4y ago
      > I'm talking about product design, not technical design. Even worse!
      - wpietri 4y ago
        Ok? I'm telling you I have done it and it works well. If all you want to do is squawk about it, I guess I'll make my exit here.

flashgordon 4y ago

"wrong companies" is it. Perhaps it is love software engineering AND coding but hate big software companies? Also with "some software companies can turn even the simplest..." You may have forgotten to add "and add metrics to these rituals as performance goals"!

jxramos 4y ago

I forget what job it was I was interviewing for but I remember being stunned at the open lack of process they had in place for trying to bother unifying all these teams to be on the same platform framework etc and instead deliberately let sub teams work with tooling that worked for them and didn't create a lot of overhead trying to coordinate and sync and share a common codebase. Every place prior to that day I had only heard of people going for long stretches to impose a company wide uniformity in tooling. All the costs associated with getting everyone on the same page was always taken as a worthy cost to pay and that future date in the promise land would have made it all worth it. The folks in this other company just flat out said not worth it, just get your stuff done, ideal development scenarios and perfect harmony and alignment have too much hidden costs to bother with. It's naturally a pro and con scenario but it was pretty refreshing to hear of folks so unconstrained by this self imposed constraint every other shop had imposed on themselves.

hn_user2 4y ago
I have seen two extremes of this. The one side is forced conformity, and the other side was complete chaos. To the point where each project was written in its own language. Imagine changing teams to help on a project and step 1 is to learn a new language and deploy methods. I feel like there is a golden middle where the team has decided on maybe 3 languages, one typed, one scripted, one cutting edge. And a few different deploy scenarios, and you can pick amongst them.
bennyelv 4y ago
I work at a company that's trying to come out of the other side of this kind of approach. Let me tell you, it might feel good while you're doing it but in 5 years time it will be a hot mess of unmaintainable garbage! There are hidden costs in trying to align as you go, but there are potentially company ending costs in not. You're right that there is no promised land, but the quest to reach it prevents you regressing into hell.

deleted 4y ago

[deleted]

goodpoint 4y ago

> Some software companies can turn even the simplest tasks into a grueling series of processes, endless meetings You mean 95% of companies.

xyst 4y ago

> Some software companies can turn even the simplest tasks into a grueling series of processes, endless meetings, and joint work across a big number of “stakeholders”. These companies will take the joy and productivity out of programming and replace it with a series of rituals and set of language that people use to go through the motions every week so they can collect paychecks. god - this is so true at my last company. Any attempts to decrease meetings, remove unnecessary process are met with heavy resistance. Getting shit done was nearly impossible. People had no responsibility for their work. Only wanted "stories" and "subtasks" assigned to them. Doesn't matter if the story was trash/useless/no-op, they just wanted it to pump their numbers because the quarter is ending. I shouldn't have tried so hard to make changes. They probably ended up getting reverted by the next person or manager. Pro tip: if the company you joined tends to hire new people then retain them. Then fucking run. During the first "all hands" in that company, nearly 80% of people that worked in the organization were hired in the past 1 year or so. It ticked "red flags" at the time but I ignored it because honestly I needed the money at the time (just graduated college)

__MatrixMan__ 4y ago
I'm confused. Aren't all companies that got a round of funding ~1 yr ago going to have a large cohort of <1 yr tenure employees? What connects this to death-by-process?
- ornornor 4y ago
  High churn company. Grind them out, throw them away when they’re not performing anymore, and replace them with a new batch of fresh meat to wear down. Standard playbook for an alarming number of (VC funded) companies.

casey2 4y ago

These processes exist for a reason, even if nobody knows what it is. Over time companies that did these things survived, maybe nowadays it is vestigial, but the burden of proof is on new successful companies that don't have these practices.

mobiuscog 4y ago
I think it's more marketing and profiteering based on correlation over causation. Almost every process these days is bought in by a new managerial hire, or after attending an event, where a talk or book that shows X companies that are very successful all followed the Y practice, and so 'we should too' as it's obviously the path to success. Rarely is there reflection on whether the process is working, and blame is laid at the feet of the workers. Despite many recollections and experiences retold about how processes may not work, they are silenced by the advocates of such processes who will show how successful they were (and also just happen to make their living by advocating rather than actually being on the ground).

inglor 4y ago

It might even be very different in the same company. I changed teams in my large company and the number of recurring meetings around process dropped from 8 to 0, no more daily, no sprint planning etc - we just talk about the feature then do it and we don’t need a lot of process since communication works well anyway.

datavirtue 4y ago

I love meeting with the right people, documenting my work, and working with legacy code. Especially meetings, nothing more invigorating than building something with a team. That said, as some have already mentioned, all of this is typically ruined somehow at nearly every company.

DrBazza 4y ago

> I can almost guarantee that you’re just at the wrong company. You're at the wrong company if you're unhappy regardless of the size. I've worked at a very small company which was miserable because the owner didn't have a clue and was only interested in the bottom line to the point of letting the software and the systems atrophy. I've worked at Megabank, and it was also miserable. Actually writing code probably ended up being a sum total of 3-4 hours a week. At best. Too many meetings. Absurd change control system. Crazy processes and sign off. And then there have been a few mid-sized companies - 20-200, and they've been the most fun. Get on with coding and even whilst managing a small team.