I don’t entirely subscribe to the first paragraph – I’ve never worked at a place so dear to me that spurred me to spend time thinking about its architecture (beyond the usual rants). Other than that, spot on
I am genuinely so thankful for my job. Small start up where the founder is funding the whole thing himself and actually works as a dev as he’s able.
The amount of autonomy I’ve had since day 1 is wonderful. I put in a lot of time because I enjoy the work. My pay is a little low but not bad and usually increases by a lot each year. We’re 100% remote.
I just can’t imagine willingly leaving after reading the nonsense that most of you are dealing with. I got so lucky and you can pry my current job from my cold, dead hands.
I believe the author got the wrong job position. If your job title is something like ‘software developer’, yeah you are measured by the amount of lines of code. You should aim for a senior role such as ‘system architect’ or ‘technical lead’, then you have some kind of guidelines from the sales side of business, and your job is to turn them into requirements and produce the final product, and you choose the tech stack and other details that are inconsequential for sales bug will get the programmers flinging keyboards.
I agree.
One can’t claim to love programming while calling the act of writing code being a code monkey. Whatever they actually love about the process may not exist in the industry.
I would suggest they explore alternative roles and perhaps alternative industries. They sound like they are new to the industry so their ability to land a senior role is likely to lead to different disappointments.
The best way to do something, often isn’t the best way to implement something. That’s why this is a senior role. The author does not appear to understand this concept and will be horribly disappointed when their perfect architecture is ignored by the realities of development.
This description is so foreign to me. I guess you’re talking about big [software] companies?
Nobody in my company, a software development company, measures by lines of code. We bring value through the software we develop and the collaborations we do.
Yes, this industry is pretty much a race to the bottom (when it comes to wages) by adding methodologies and micromanagement at every corner to make people more “productive”. It’s just sad to see that most people don’t realize that they’re in the race to the bottom just because IT is still paying more than average and/or doesn’t require as many certificates as other fields to get into. The downside of the lack of professionalization is that people abuse developers everyday and the benefits like having more freedom to negotiate your higher than average salary are quickly vanishing in the fact of ever more complex software and big consulting companies taking over internal development teams and departments companies used to have.
To make things worse cloud / SaaS providers keep profiting from this mess by reconfiguring the entire development industry in a way that favors the sell of their services and takes away all the required knowledge developers used to have when it came to development and deploying solutions. Companies such as Microsoft and GitHub are all about re-creating and reconfiguring the way people develop software so everyone will be hostage of their platforms. We now have a generation of developers that doesn’t understand the basic of their tech stack, about networking, about DNS, about how to deploy a simple thing into a server that doesn’t use some orchestration with service x or isn’t a 3rd party cloud xyz deploy-from-github service.
Consulting companies who make software for others also benefit from this “reconfiguration” as they are able to hire more junior or less competent developers and transfer the complexities to those cloud services. The “experts” who work in consulting companies are part of this as they usually don’t even know how to do things without the property solutions. Let me give you an example, once I had to work with E&Y, one of those big consulting companies, and I realized some awkward things while having conversations with both low level employees and partners / middle management, they weren’t aware that there are alternatives most of the time. A manager of a digital transformation and cloud solutions team that started his career E&Y, wasn’t aware that there was open-source alternatives to Google Workplace and Microsoft 365 for e-mail. I probed a TON around that and the guy, a software engineer with an university degree, didn’t even know that was Postfix was and the history of email.
All those new technologies keep pushing this “develop and deploy” quickly and commoditizing development - it’s a negative feedback loop that never ends. Yes I say commoditizing development because if you look at it those techs only make it easier for the entry level developer and companies instead of hiring developers for their knowledge and ability to develop they’re just hiring “cheap monkeys” that are able to configure those technologies and cloud platforms to deliver something. At the end of the they the business of those cloud companies is transforming developer knowledge into products/services that companies can buy with a click.
I am more alienated by the processes surrounding everything. If I had to do idiotic agile sprint bullshit and also write mind-numbingly boring code I would lose my mind. Luckily I have gotten away with making improvements in architecture so it is at least an interesting problem on occasion.
It sounds like this author would feel better working on open source, a passion project, or a deep academic paper. I think I’d prefer that also. I wish it were easier to live while doing that.
Unionize
I had the same issue with gamedev industry, but thankfully Ive very quickly realized that’s how work works, and you usually have a choice - either earn a good living being a code monkey, or find a job in a small company that has passion, but they won’t be able to afford paying you well, or do it in your free time as a hobby. Capitalism and passion doesn’t work together.
So I went to work part-time in cybersecurity, where the money is enough to reasonably sustain me, and use the free time to work on games in my free time. Recently, Ive picked up an amazing second part time job in a small local indie studio that is exactly the kind of environment I was looking for, with passion behind their projects - but they simply can’t afford to pay a competitive wage. But I’m not there for the money, so Ibdon’t mind and am happy to help them. Since there are no investors whose pocket you fill, but the company is owned by a bunch of my friends, I have no issue with being underpaid.
But it’s important to realize this as soon as possible, before trying to make a living with something you’re passionate about will burn you out. A job has one purpose - earn you a living. Companies will exploit every single penny they can out of you, so fuck them, don’t give them anything more than a bare minimum, and keep your energy for your own projects.
And be carefull with trying to earn a living on your own - because whatever you do, no matter how passionate are you, if it’s your only income and your life depends on it, you will eventually have to make compromises to get by. It’s better to keep money separate from whatever you like doing, and just keep your passion pure.
EDIT: Oh, I forgot to mention one important thing - I’m fortunate to not have children, share living costs with a partner, and live in a city with good public transport, so no need for a car, and free healthcare. I suppose that makes it a lot more easier to get by with just a part time.
either earn a good living being a code monkey, or find a job in a small company that has passion
crazy idea: let’s publicly fund FOSS projects so devs working on stuff they like with a passion can actually make a good living and enable sustainable non-profits to hire expertise, marketing and all the stuff a company needs
the result would be actually good software and happy devs
Ok let me know how you plan on getting other people to fund that.
Public funds.
There actually are lots of initiatives (e.g. https://bigdatastack.eu/european-open-source-initiative ) but it’s still young and there are multiple problems between available public money and contributors actually earning a salary.
Money is not the problem.
I’m starting to think that “good code” is simply a myth. They’ve drilled a lot of “best practices” into me during my masters, yet no matter how mich you try, you will eventually end up with something overengineered, or a new feature or a bug that’s really difficult to squeeze into whatever you’ve chosen.
But, ok, that doesn’t proove anything, maybe I’m just a vad programmer.
What made me sceptical however isn’t that I never managed to do it right in any of my projects, but the last two years of experience working on porting games, some of them well-known and larger games, to consoles.
I’ve already seen several codebases, each one with different take on how to make the core game architecture, and each one inevitably had some horrible issues that turned up during bugfixing. Making changes was hard, it was either overengineersled and almost impenetrable, or we had to resort tonugly hacks since there simply wasn’t a way how to do it properly without rewriting a huge chunk.
Right now, my whole prpgramming knowledge about game aechitecture is a list of “this desn’t work in the long run”, and if I were to start a new project, I’d be really at loss about what the fuck should i choose. It’s a hopeless battle, every aproach I’ve seen or tried still ran into problems.
And I think this may be authors problem - ot’s really easy to see that something doesn’t work. " I’d have done it diferently" or “There has to be a better way” is something that you notice very quickly. But I’m certain that watever would he propose, it’d just lead to a different set of problems. And I suspect that’s what may ve happening with his leads not letting him stick his nose into stuff. They have probably seen that before, at it rarely helps.
There’s bad code and then there’s worse code. “Best practices” might help you to avoid writing worse code.
Good code might appear occasionally. In the rare event when it’s also useful, people will start to have opinions about what it should do. Suddenly requirements change and now it’s bad code.
“Best practices” might help you to avoid writing worse code.
TBH I am not sure about this. I have seen many “Best practices” make code worst not better. Not because the rules themselves are bad but people take them as religious gospel and apply them to every situation in hopes of making their code better without actually looking at if it is making their code better.
For instance I see this a lot in DRY code. While the rules themselves are useful to know and apply they are too easily over applied removing any benefit they originally gave and result in overly abstract code. The number of times I have added duplication back into code to remove a layer of abstraction that was not working only to maybe reapply it in a different way, often keeping some duplication.
Suddenly requirements change and now it’s bad code.
This only leads to bad code when people get to afraid to refactor things in light of the new requirements.Which sadly happens far to often. People seem to like to keep what was there already and follow existing patterns even well after they are no longer suitable. I have made quite a lot of bad code better by just ripping out the old patterns and putting back something that better fits the current requirements - quite often in code I have written before and others have added to over time.
This only leads to bad code when people get to afraid to refactor things in light of the new requirements.Which sadly happens far to often. People seem to like to keep what was there already and follow existing patterns even well after they are no longer suitable. I have made quite a lot of bad code better by just ripping out the old patterns and putting back something that better fits the current requirements - quite often in code I have written before and others have added to over time.
Yup, this is part of what’s lead me to advocate for SRP (the single responsibility principle). If you have everything broken down into pieces where the description of the function/class is something like “given X this function does Y” (and unrelated things thus aren’t unnecessarily coupled) it makes reorganization of the higher level logic to fit the current requirements a lot easier.
For instance I see this a lot in DRY code. While the rules themselves are useful to know and apply they are too easily over applied removing any benefit they originally gave and result in overly abstract code. The number of times I have added duplication back into code to remove a layer of abstraction that was not working only to maybe reapply it in a different way, often keeping some duplication.
Preach. DRY is IMO the most abused/mis-understood best practice particularly by newer programmers. DRY is not about compressing your code/minimizing line count. It’s about … avoiding things like writing the exact same general (e.g., a sort) algorithm inline in a dozen places. People are really good at finding patterns and “over fitting” making up abstractions that make no sense.
Yup, this is part of what’s lead me to advocate for SRP (the single responsibility principle).
Even that gets overused and abused. My big problem with it is what is a single responsibility. It is poorly defined and leads to people thinking that the smallest possible thing is one responsibility. But when people think like that they create thousands of one to three line functions which just ends up losing the what the program is trying to do. Following logic through deeply nested function calls IMO is just as bad if not worst than having everything in a single function.
There is a nice middle ground where SRP makes sense but like all patterns they never talk about where that line is. Overuse of any pattern, methodology or principle is a bad thing and it is very easy to do if you don’t think about what it is trying to achieve and when applying it no longer fits that goal.
Basically, everything in moderation and never lean on a single thing.
We have an almost total lack of real discipline and responsibility in software engineering.
“Good enough” is the current gold standard, so you get what we have.
If we were more serious there wouldn’t be 100 various different languages to choose from, just a handful based on the requirements and those would become truly time worn, tested and reliable.
Instead, we have no apprenticeships, no unions, very little institutional knowledge older than a few years. We are pretending at being an actual discipline.
