Hello, friends!
I’ve been thinking back on my career recently, which I’ve had plenty of time to do, considering that I am exploring creative outlets like blogging, and that I’m currently in between jobs. One thing that I’ve felt slowly creeping up on me is this strange-sounding idea that software development has too much software in it.
As someone who talks a lot about software with friends and acquaintances, and engages heavily with technology both on and off the clock, this sounds like a very odd thing to say, but I think my thesis will become more clear as you read on.
I originally got into software development because I wanted to learn more about how technology worked under the hood, and because I wanted to help contribute to open-source software however I could. Eventually, I made software development my profession, and I began to notice some peculiarities of writing software for a living in corporate environments. The complexity around tooling increased, obviously, as I started slinging code for a paycheck, sometimes for reasons that were more in the interest of the company than delivering exactly what the user needed.
As an example, React or some other heavy client-side JavaScript framework are often asked for in job descriptions. I always found this a bit odd, as most places that asked for this kind of front-end didn’t have an apparent need for it. Arguably, they could solve their problems with server-side rendering of HTML and some light JavaScript, especially for internal applications that would probably not be used on mobile, anyway. This is supposedly done for standardization and ease of hiring, but I’m sure a developer who can tackle the task of learning and using React and its ecosystem effectively would easily be able to learn a lighter weight, simpler front-end library or framework
Speaking of tools of the trade, it’s becoming well-known that software developers change jobs a lot, sometimes to increase compensation, and, as in my case, sometimes to escape a toxic workplace, or because contracts are becoming increasingly common, as opposed to full-time work, though those are whole separate blog post on their own. One of the big drawbacks to this is constantly having to learn new software architectures and environments. Even within two tech stacks that seem similar, such as two Spring Boot codebases, or especially JavaScript codebases, there is a lot of domain knowledge to learn, and more to the original point, the JavaScript ecosystem encourages you to piece your app together any way you like, rather than using frameworks. There’s enough things that can change between apps, like onboarding processes, database setup, VPNs, having to message a ton of different people to get permissions to access things, that I wish we could simplify and standardize the actual layout of the code, as an industry.
I can see some possible benefits to this approach, but I’d much prefer that we just stick to frameworks, unless there’s a clear reason not to.
Another drag on software and its developers is the overemphasis some places have on unit testing, even extending to unit tests in the UI! At one of the places I worked, they had terrific technical processes, and all my teammates were stellar, but the director of software development would endlessly insist on testing code, aiming for at least 85% code coverage. This made it so that I spent a small fraction of my time writing new code and actually delivering new functionality, and the majority of my time getting tests in place and working. Weirdly, the fact that we used a design library called Ant Design actually made some components impossible to test, so we would have to manually override the code coverage requirement sometimes.
The sheer amount of time spent on unit testing easily nullifies whatever benefits were gained from doing so much of it in the first place. A big saving grace of this particular company, though, is that the QA team were great folks who really opened my eyes to what a pleasure it was to work with an actually good QA team!
A big gripe I have with how software developers are often expected to operate is that they are often told what the requirements for the software are by a BA or some other liaison between them and the business, the developer is permitted to ask some arbitrary amount of questions (“not too many!”, “not too few!”), and then is basically told to shut up and do the work. Later, we are told that we should feel empowered to not just be software engineers, but to really, deeply care about the product, and to take ownership.
The only problem is that we often aren’t really given ownership, but are nonetheless expected to behave like and care as much as owners. I’m aware that this issue isn’t just a problem that software developers have, and that all white-collar workers experience this alienation to some degree. It’s just that we are often told that the goal of software development is to create value for the business and its customers, but the business seems to be unwilling to let developers actually do that. To top if off, companies love to lay people off long before they can get truly familiar with the business itself, the domain, and the various codebases within.
A final thing that comes to mind right now is the AI fatigue. AI tools constantly being released and improved, and the chatter around the AI tools themselves, as well as the constant ruckus around whether they’ll replace developers or not, is omnipresent and tiring. I wish people could just acknowledge that they are just another tool, and are not going to be the be-all, end-all of software development for a while yet. Unfortunately, misusing this particular tool won’t just mean that you can’t achieve your goal; you’ll also leave a trainwreck of a codebase in your wake.
Please discuss in the comments anywhere where you think software has gone a tad overboard. I love the craft, but it is important to discuss how we can improve the tooling and day-to-day experience of our craft!
I’m working on getting better on expressing myself through blog posts, so I can teach and encourage people on the Internet. Please leave any feedback or ideas for improvement you have, and subscribe! 🙂
Leave a Reply