Tell HN: I love programming but am sick of the software industry
I have >20 years experience programming, at least 10 of those professionally. I've been programming since I was in grade school. It started with a spark of creativity, I loved making things come to life on the screen.
My early years freelancing were full of learning. It was challenging, there were difficult times, but it was almost always interesting. Then I went and got a full-time job. In just a few short years the professional software industry had burnt through just about every drop of passion I had.
Learning. I stopped learning at work. Few people are interested in anything that might make the job easier, if it means they have to learn something. Senior engineers especially are paranoid because of bad past experiences and afraid of anything they haven't seen before. Instead we spend months writing overly complicated AbstractBeanFactoryFactories because "that's the industry standard". Because its "easier to hire Java devs". I'm just shocked at how resistant people are to new technologies and ideas that could make things so much easier, especially more senior engineers. Because I love learning, I spend my spare time at home learning about functional programming, new languages, patterns, all sort of things just out of interest. 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".
Code reviews.. (continued in comments below)
32 comments
[ 4.1 ms ] story [ 66.9 ms ] threadTickets, 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?
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").
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.
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.
> 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.
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.
> 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.
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.
https://www.firstcallonline.us/
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.
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.
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.
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.
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 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.
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 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.
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.