3 ms·

Something I've realized lately is that I like programming, but I hate programming on a team. (Before you say it: I'm good at working on a team, I get along well

Something I've realized lately is that I like programming, but I hate programming on a team. (Before you say it: I'm good at working on a team, I get along well with my teammates, and my managers only have good things to say about me and my work.) It doesn't matter how good the team is, the software development process seems to suck all the joy out of programming. At least for me. I'm hoping that I can either retire early, so that I still have time to enjoy programming on my own terms, or can somehow pivot to being a solo dev (which comes with its own pitfalls, of course).

armchairhacker 5y ago
I like programming, I hate programming on legacy software with very slow build times and odd design decisions. Bonus if the task is purely debugging, like “get this to load faster” instead of making new features. Probably why a lot of apps get bloated with feature creep.
ilkhan4 5y ago
Yeah, I'm with you. I was effectively a solo dev for a few years and definitely had a "grass is greener" mentality so I joined a team. I quickly realized the grass was not greener. I think my ideal is working on a project solo, but still having other folks (doing other projects) to bounce ideas off of.
karmakaze 5y ago
I know where you're coming from. I've experienced the shock of switching from a nimble startup to a large tech co with teams for UX research, web, mobile, backend, platform, infrastructure, observability. Took a good while to get used to it. Each project has had it's prototype phase where core stuff gets figured out and a proof-of-concept validated. The productionization and stream of shipping PRs to deliver that over the next N months can be a lot. Then a new project starts and things are new and interesting in new/unknown ways. Pair programming helps, it's like watching a movie you like where you know what happens with someone who hasn't seen it before. One thing that would help here is if new initiatives are new delivered artifacts rather than being tied to the CI/CD process of the established product. I haven't worked at a place that does this, but have worked at a place that didn't to its great detriment--instability of core product from changes made by new and slow new product development hindered by being in same monolith. Whenever I see a posting about a bank or other saying that we're big but have a small startup-mentality team, I don't buy it. Would love to find out I'm wrong on that. I can't say for sure if any of those many startups where I did really cool stuff still runs those products. Possibly only in a sort of maintenance mode. What I'm working on now has more chance of being the foundation for something that lasts a lot longer, so taking a very long-term view makes it worthwhile. I still do look fondly on the scrappy startup style of working in a small tight platform/API team where you can have a super technical discussion using so few words because you already know where the thoughts are headed.

armchairhacker 5y ago

I like programming, I hate programming on legacy software with very slow build times and odd design decisions. Bonus if the task is purely debugging, like “get this to load faster” instead of making new features. Probably why a lot of apps get bloated with feature creep.

ilkhan4 5y ago

Yeah, I'm with you. I was effectively a solo dev for a few years and definitely had a "grass is greener" mentality so I joined a team. I quickly realized the grass was not greener. I think my ideal is working on a project solo, but still having other folks (doing other projects) to bounce ideas off of.

karmakaze 5y ago

I know where you're coming from. I've experienced the shock of switching from a nimble startup to a large tech co with teams for UX research, web, mobile, backend, platform, infrastructure, observability. Took a good while to get used to it. Each project has had it's prototype phase where core stuff gets figured out and a proof-of-concept validated. The productionization and stream of shipping PRs to deliver that over the next N months can be a lot. Then a new project starts and things are new and interesting in new/unknown ways. Pair programming helps, it's like watching a movie you like where you know what happens with someone who hasn't seen it before. One thing that would help here is if new initiatives are new delivered artifacts rather than being tied to the CI/CD process of the established product. I haven't worked at a place that does this, but have worked at a place that didn't to its great detriment--instability of core product from changes made by new and slow new product development hindered by being in same monolith. Whenever I see a posting about a bank or other saying that we're big but have a small startup-mentality team, I don't buy it. Would love to find out I'm wrong on that. I can't say for sure if any of those many startups where I did really cool stuff still runs those products. Possibly only in a sort of maintenance mode. What I'm working on now has more chance of being the foundation for something that lasts a lot longer, so taking a very long-term view makes it worthwhile. I still do look fondly on the scrappy startup style of working in a small tight platform/API team where you can have a super technical discussion using so few words because you already know where the thoughts are headed.