Tell HN: I love programming but am sick of the software industry

You're not wrong to want to write code your way. Not everyone is meant to conform to the absurdities you describe. Honestly, I don't know how you tolerated it for this long.

Write code your way for yourself. Find a way to turn a profit on your own. Solve problems that create passive income for you.

Being yourself is perfectly valid. I'm not sure therapy is healthy if conformity is the desired outcome. Others might have ways of putting you in boxes and providing shifting diagnoses. That's fine. Ignore it and do your own thing.

Earn your own money, your own way. Embrace your eccentricities. Use them to your advantage. When you are successful, people will look to you as a standard or model for correct behavior. Therapy won't be recommended.

Thank you, I needed to hear this.

> I'm not sure therapy is healthy if conformity is the desired outcome.

It's taken me an embarrassingly long time to realise this. Somehow I always knew it in the back of my mind, a sort of quiet rebellion, but the "logical" part of my mind (actually the little voice of society) always took the reins.

> Earn your own money, your own way. Embrace your eccentricities. Use them to your advantage.

This is something I've been dreaming of for years, but actually following through on it is difficult. In my experience conquering the self-doubt has been the hardest part, but after that there's still the hurdles of finding customers.

Most of the jobs at the SW industry are traditional office jobs, specially in consultancy companies. There is a task that has to be done. That's all. Nobody wants to be responsible for the problems that may appear after applying a "novel" methodology. And that is perfectly normal. At the end of the day most people want to have their job done and go home.

As a personal recommendation, if you are in a job where you observe many overcomplicated practices, stale methodologies, and a lack of innovation the best thing you can do is to look for another position. You may be surprised but there are more people like you around there.

I hate my job.

I see what you mean about resistance to change. I've encountered it, although usually from a process/system/logic perspective rather than straight technology. Stuff like my prior tech lead wanting to build out a complicated screen to rerun jobs/items in the system. The reason for this is the support team needs help with this. The reason they need help with it, is because we don't have documentation on how to handle each issue. So instead of simply creating the documentation and having knowledge transfer, he wants to build out a new screen... which would require additional documentation, maintenance, and knowledge transfer.

I've also seen the other way, where they are too accepting of new technology. It's a constant parade of new stuff on my current team. We have integrations for cloudwatch, splunk, opentelemetry/honeycomb, servicenow, pagerduty, a data lake, tableau, etc. I get that some of these enable specific features, but a lot of them seem are redundant (especially the way we use them) . Can we just pick one alerting system, one logging system, and one reporting system? And maybe we can stick with that system for a few years instead of refactoring to integrate the newest thing into our 5-10 apps almost as soon as we finished the integration of the prior thing. All that churn could be better spent delivering value and just integrate the new service when it's truly compelling. Maybe we could get rid of the prior services that are essentially being replaced to increase the maintainability too and streamline the process.

In my company, the resistence to or over adoption of new tech is really just a facade concealing a bigger issue with the underlying processes of the system itself, the bureaucracy, or the business processes.

I'll give you an a look into the company I work for ( a small saas thats already 15 years old). We constantly look to upgrade our systems and processes starting from colocated servers finally to docker and aws hosting with testing automation. We've grown or QA team and automated testing team greatly and always allow room for better tools and processes. I work as UX and product as well as some development. 6 years ago we migrated to angular and now we are onto React and storybook and several other tools that help us build better software. The backend team has gone from DIY php to symphony then to java and finally to kotlin. We have a weekly book club where we go through one chapter of a tech or business process book. I guess from all of this I can suggest you find a (usually smaller) team that's responsible and willing to make the job interesting yet make sense from a business perspective. Personally developer happiness is a significant (though not majority) part of that equation including pay. I hope this has been helpful at least in providing ideas that may work for you. Good luck

I used to be a Java developer and now I am a Golang dev. I moved from a very large company (1000's of devs) to a medium size one (about 100 devs) and would say there are interesting difference in the culture of developers around languages. My experience is that Java shops have a way of doing things based on years of debate. However, I also noticed that there where a lot of devs who just took the "best practices" at face value without much thought so there was a huge amount of friction when you wanted to do something different. Largely centered around who didn't really know why they did stuff a specific way. When I switched to a Golang shop it was much different, a lot more freedom around what to do as there was just not enough time for all those "industry standard" ways of programming to take root. I like this freedom, and the learning that goes with it, a lot more though it dose come at a cost. I have seen several coding practices I feel will cause issues, use of global variables to do testing for mocks, singletons, things like that. Basically, what I am saying is you might want to try a job that operates in a newer language if wanting to try new things is what you are looking for. If the company is open to a newer language the are probably open to new ideas as well. That has been my experience at least.

Programming, at least what is called programming when we like to do it solo without constraints, and corporate software engineering (what we do for payment) are completely different things. I like programming actually and corporate programming is necessary evil for money which somewhat distantly resembles what you like. If you separate those things you won't have a confusion. Corporate software engineering is somewhat boring and frustrating indeed, it's still better ratio of boredom/comfort/payment than any other speciality for me and my skills.

About misconceptions in community, indeed there are a lot, and they are too deep to overturn it singlehandedly in a reasonable time, they are established by a ton of smart/intelligent people and learned like a dogma by other normals. There's no hard proof of those patterns, paradigms so it's some kind of religious belief you'd better not argue with or will be burned at the stake. Be happy it's only a metaphor.

> AbstractBeanFactoryFactories

I absolutely get what you mean and it sucks. I too love learning (and arguing, which doesn't help you that much on the job...)

I think these practices grow themselves out, but it takes quite some time. On the other hand, I can be defensive too if people just want to rewrite software to change the implementation language. It always sounds fun at first until you grasp the complexity of the project again.

> Tickets, JIRA, daily standups, scrum masters, sprint planning, backlog grooming sessions. Why does nobody question any of this "best practice"?

In my experience these are use to give people outside of software (and some developers) an illusion of control. If you can identify that want and can supply it with different means, you may be allowed to just skip it. I hate scrum, I like coffee breaks with colleagues. Of course that might not scale for the largest companies, don't know.

> I know some of you may say I should go get checked out for depression

On the contrary, depression stifles compassion for the craft. Like JIRA and daily standups or other formalities. As I said, if you can reduce the fears of management, they tend to give you the freedom you want. If other devs don't like that, go to management and make them your minions.

Appreciate the comment.

> On the other hand, I can be defensive too if people just want to rewrite software to change the implementation language. It always sounds fun at first until you grasp the complexity of the project again.

Yep, I'd agree with you here, fun new things for fun new things sake is usually a mistake. The cases I'm talking about though are where a slightly less commonly used pattern could actually drastically simplify the problem, but the other party is so set in their own mindset and way of doing things that they're unwilling to do it differently.

> In my experience these are use to give people outside of software (and some developers) an illusion of control.

Yes, perhaps that's it. The challenge is that in the last few jobs I've been in, the team themselves have also been in favor of these processes. The teams I've worked with seem to love just picking off tickets, having someone chop up work, and sitting in backlog grooming etc.

I'm a PM. I spend a lot of time managing the standup, sprint planning, etc. We have to do that stuff because otherwise the engineers wouldn't do things that the business needs. What engineers are interested in, passionate in -- don't often translate into what the business needs. So we have to do these processes to make it happen. I'm sorry that we do this to you.

Software development was fine without daily roll call. I honestly find it funny that grown adults have to tell their bosses what they did yesterday and what they will do today.

The questions give a frame to the meeting but usually the important part is what is finished, who waits on what and who stuck on something. I know a few senior dev whom if I would lead daily standups would be unnecessary but that is called a dream team. Reality is littered with juniors, subpar programmers and devs only interested in tech not in business.

It’s sometimes important to have a little oversight to make sure people are working on the right things. Junior engineer spending 3 days on the same tiny bug? Maybe they need some help. Senior engineer clearly over-optimizing a system? Time for a new meaty project.

Code reviews. There's good reason for them to exist, but in practice at best they're a waste of time, and at worst an exercise in narcissism. People nitpicking the way a statement is written because they feel like their subjective preference is objectively better. Perfectionists who block forward progress in attempts to pick out every possible detail that doesn't matter in the big picture, instead of moving forward with 80% good. Choosing a worse solution that a reviewer suggests because you know they're always the last to back down. And code reviews rarely catch the bugs that actually matter.

Tickets, JIRA, daily standups, scrum masters, sprint planning, backlog grooming sessions. Why does nobody question any of this "best practice"? Why do we all just collectively accept these processes that take any and all enjoyment out of the profession, and makes every person feel like a replaceable cog. Is it because of this industrial age idea that work is supposed to be boring, that we should just suck it up? Aren't we way past that now, in the 21st century? Are there others out there who don't hold such a defeatist view of work? Where are you all?

I know some of you may say I should go get checked out for depression, and I do appreciate the concern. In the past I've had years of therapy for depression/anxiety, and it has helped me cope. But I know what depression is, and this isn't it. I spent years believing that the problem lies with me, but I'm finally starting to get the courage to see that maybe it's the industry that needs therapy too.

I took quite a few months off between jobs recently and felt the passion start to come back. I felt great, excited about work again. I got some projects off the ground (and much more quickly than I ever could in a job) but they didn't really take off. Now I'm back at work and the passion is evaporating again.

I know that there's still a passion under there. I know that work doesn't have to be like this. I'm increasingly convinced that 90% of modern software "best practice" is bullshit that has moved our industry backwards, not forwards. It's as if we've collectively turned ourselves from craftsmen into factory workers.

I appreciate you reading this far into this huge pile of negativity. Now that that's off my chest, what do you think of "best practice" in software in 2021?

> Code reviews. There's good reason for them to exist, but in practice at best they're a waste of time, and at worst an exercise in narcissism. People nitpicking the way a statement is written because they feel like their subjective preference is objectively better. Perfectionists who block forward progress in attempts to pick out every possible detail that doesn't matter in the big picture, instead of moving forward with 80% good. Choosing a worse solution that a reviewer suggests because you know they're always the last to back down. And code reviews rarely catch the bugs that actually matter.

I found that code reviews without a design review or at least a description of the proposed design in the PR itself, is nothing but a waste of time the way you just described.

Imagine a Civil Engineer being walked through a construction site and making comments right about work, while even though he knows the fellas are building a bridge, he has no idea how that bridge ought to look like etc. This becomes a waste of time because I have to read the diff and build a mental model, which is at best a guess, of what the author wanted to build/change based on just the diff. This is even worse with code bases I'm barely familiar with (which is increasing since we have a bunch of "micro services").

Re: Code Reviews

Like anything there are good versions and bad versions. I think we've all been through bad code reviews and bad code review processes, so let's skip talking about those. On the other side, here's what good code reviews/processes I've been a part of accomplish:

1. The give the creator of the code the opportunity to rubber-duck. I've found that 80+% of all bugs found in code (before merging) are found by the programmer themself just by talking through what each change is meant to accomplish.

2. The give the reviewer(s) the opportunity to ask very simple questions and questions about how the code change relates to other major systems that the PR creator may not even be aware of. If there are any remaining issues with the change (the last 20%) this is usually where they are found. This isn't about where to put curly braces. If your team cares about that, use auto-formatting tools or something.

3. It gives somebody... ANYBODY... other than the PR creator, some idea of what the code does and why. This is absolutely critical as it spreads the bus factor. When something goes wrong and a programmer is sick, on vacation, or has left the company, it's critical that there be one or more other programmers who can pick up the mantle. They may not have deep knowledge, but they aren't coming into the code blind either.

4. Building on 3, it spreads the architectural knowledge and decision making of the code base among all the programmers. Code reviews shouldn't only be "run" by senior/lead programmers. Senior programmers should be getting reviewed by junior programmers as well. It's not ego or about teaching. It's about realizing we all make mistakes and we all contribute to the same end goal. Over time, everyone becomes aware of the systems at play and what's going on. When they are presented with a task, they have a much deeper understanding of what's involved, they can estimate better, and they are aware of who else to talk to or involve in the process. Junior programmers will get comfortable speaking up in architectural meetings and bring up good points. This is one way they become senior programmers.

Thats because “best practices” only apply in simple situations. In complex dynamic situations made of humans with feelings, there are only “good practices” which might be applicable in context.

Using Java doesn’t mean you have to name everything AbstractFactoryFactoryBean. That’s just general bad development no matter what language is used. My personal hate is over engineered solutions with too many latest fashionable technologies shoehorned in for the sake of using them. Especially 5 years later when you have to deal with them.

> Using Java doesn’t mean you have to name everything AbstractFactoryFactoryBean

The problem with AbstractFactoryFactoryBean isn’t the name. In the complaints about things like that, the names are used because they are well-chosen, appropriate names for the things being complained about.

At the end of they day class names like that solely come from the GOF design patterns. Nothing to do with any language. I think I’m ready to leave the software industry now too to be honest.

> At the end of they day class names like that solely come from the GOF design patterns.

The GOF design patterns are influential as boilerplate templates in certain language communities precisely because they solutions to commonly-encountered problems that are not easily reducible to generic, reusable components in those languages.

Design patterns — in the boilerplate template sense, though not the underlying concept — are a language smell, not a language-independent feature of the software industry.

> Design patterns — in the boilerplate template sense, though not the underlying concept — are a language smell,

Underrated comment. In C++/Java, one must turn to GoF patterns to accomplish much of what's supported using basic syntax in many other languages (e.g. first-class functions, extensible objects, coroutines, prototypes, flexible parameter types, functional composition).

When it was published, Design Patterns must have seemed sad (or perhaps vindicating) from the perspective of a seasoned Lisp developer.

I think this starts to boil down to those who like OO and those whose don’t.

Real OO looks almost nothing like C++/Java. If you listen to one of the fathers of OO, like Alan Kay, talk about these languages, they'll say as much.

C++-style indirection, I'd argue, is the invention of Bjarne Stroustrop. He's a very smart guy, but for C++ I think that's an unfortunate thing, because he didn't come to programming language design with a desire for elegance or simplicity.

Smalltalk probably best embodies true OO principles, and it has a profound elegance and simplicity about it. (And yes, many GoF patterns are easy to use without even realizing one is using them -- first-class functions and message passing/late binding make sure of that.)

> I think this starts to boil down to those who like OO and those whose don’t.

I don't think so; there are OO languages where many of the GoF patterns can be implemented in libraries, or are trivial given language builtins.

I can't remember where I read it, but I read something along the lines of: "Technical debt is just code nobody can read anymore." A lot of us old timers have seen so many paradigm changes that we just don't care - we are focused on whether it solves the problem and whether it is maintainable.

Switching from the "hot" framework we started using last year to the "hot" framework that everybody loves this year is a step backwards from actually solving any problems. And two steps back from being able to maintain the resulting system. The world of startups is so very "now" focused that I think a lot of people (especially on Hacker News) forget that most programmers are still dealing with code written 20, 30, 40 and in extreme cases 50 years ago.

Better is great. Easier is great. But most old code can't be refactored, only replaced. Which means everything that interoperates with that old code has to either be replaced or it has to work exactly the same way. Sometimes that makes sense. Sometimes that's an absolute disaster.

Something that looks "simple" to you really can be too complex in a greater context. Rant all you want, this is just a fact of life. The software development profession has been so fascinated with shiny new toys for the past 25 years that we tend to forget that the hidden (and dangerous) part of the iceberg is not only in the past, but what we're creating now will just make it all that much bigger and more dangerous unless we're very careful.

But. I know places that are so stuck in the past that they are paralyzed and can't do anything at all. There certainly is plenty of "we've always done it this way" that needs to be thrown out the window. Introducing some new workflows or tools could really simplify things moving forward. The problem is knowing which is which. In order to know which is which you need someone who understands the system(s) at a "heroic" level.

I see us moving that way with things like "full stack" or "devops", but those are mostly only considering newer software. Making 30+ years of IT infrastructure work effectively and efficiently really is an epic task. And not one most CIOs I know of are at all capable of.

Sorry, I guess you triggered a flood of things I've been thinking about this past year. I guess I would sum it up by saying that your own rant is very personal and doesn't necessarily take the context that software is developed within into account.

I got bad news, lawyers and automation engineers will make software development even more boring in the next years. More responsibilities to comply, less of those simple tasks that let you breath between hard problems. I work in automation for one of the big SW/HW players.

> I'm just shocked at how resistant people are to new technologies and ideas that could make things so much easier

> I see how so many things we take as standard in the industry are incredibly slow, overcomplicated and inefficient, but when I try to introduce new ideas or patterns at work they're unfamiliar and therefore "too complex"

Almost everywhere I've worked there is always resistance to change - but not always because people are too lazy to learn new things. There's an inherent cost for a team to adopt something new - there's no free lunch. Especially when it comes to new technologies, if your team doesn't have the chops to dig into the source when things go wrong, you're probably not going to have a good time even if they do adopt it. And new technologies can be incredibly complex - can your team manage the complexity? Who will support and own the builds, the deployment process, troubleshooting, etc? People who cry at the first sign of trouble will continue to do so.

You have to justify it to the team, the manager, or the business. Oftentimes if you ask for permission to add something new, you'll probably never get it. If you go ahead and prove empirically to everyone that it works, and it works better than the old stuff, that's a great way to start adoption.

Of course, if you still can't get adoption without legitimate reasons for pushback, I'd say the team culture is the real problem. People on the team think learning new things is more work, and why work more for no pay increase - especially for a job they don't really care that much about anyway?

If you work on one of these teams, you might as well just power through objections and just do whatever you want. What do you have to lose? Even if you get fired, big whoop - you weren't gonna last long there anyway. Of course, this is all predicated on the fact that you are competent and not just automatically dismissing real concerns of teammates - if you go full cowboy and actually break everything, you deserve the consequences.

I've worked at awful places like that too, but I've been able to find the top 5% of competent folks and work with them to make life more tolerable. It's hard to find a place with curious folks that dig super deep into stuff. You have to really grill the interviewers or ask to see their codebase, or know someone who already works there. I only interview with places where previous coworkers I trust already work on the team now to avoid this problem.

Are you sick of "the software industry", or of your specific job?

I've had multiple jobs that have been this way, so I'm extrapolating across the industry. But to be fair the industry is small here and all the companies poach employees from each other. So it might be a regional problem.