However
> The corporate world doesn’t give a shit about finesse, abstractions, witty or beautiful code.
Guess I’m the corporate world then! Listen here, dear colleagues: Before attempting any finesse, abstraction, wit or beauty, maybe first try to make it work to spec. Because otherwise it is entirely worthless.
If you are reasonably good at making it work, you can then make it right and maybe even fast.
Whuahaaaha ... If only that was so easy. Once you get it working, it will in most cases be torn from your hands and you will not get to touch it again any time soon. So what one does to find even a little bit of joy is to try to get some sense into that code right away, because you don't usually get a second chance.
If I knew, that at a later point in time I will only have to ask and sure enough I will get the opportunity to make things well-made, then I would be much more willing to not spend any additional time into making things well in the first run.
Making things well requires knowledge and craftsmanship, while making things merely as shoddy as possible but according to spec will requite a bunch of interns making a pile of unmaintainable crap. Code only written with the next goal in mind, not looking out for the casualties along the way.
Many try do it all at once and then end up with… nothing.
In my professional experience, the only spec you get is a wishlist, never quantified, always vague. Half the work is figuring out what the customer wants.
The only metric that anyone cares about is speed. You need to go fast, but to where? There is no consensus.
The PoC becomes a pilot becomes production becomes an exit becomes someone else’s problem. That’s the SLDC that has gotten us to a place with endless amounts of terrible software everywhere you look.
Though, I’m optimistic that at some point, the software industry will be so saturated, all the products have all the features, and the only place left to differentiate or disrupt will be quality.
That’s basically the only important context. If you can’t deliver that, it doesn’t matter how well thought through, extensible, or scalable it is.
And a substantial portion of the rest is telling them why they might be better off asking for something a little different.
So it's a conflict of names, a matter of proper identification.
If that's not for you, you need at least a requirement engineer between you and the customer. That's also okay.
From my experience, getting things done quick is almost never relevant. Getting things done “cheap” is.
I also tend to find that folks who write quick and dirty code “to spec” leave it riddled with bugs and unhandled corner cases.
1. Get it working.
2. Get it working well.
3. Get it working fast.
Your last sentence reminded me of that.
Maybe the people who care about business value should be the engineering managers not the people who equate their personal aesthetic preferences with the only right way to write code?
On the other hand, my employer advertises clean code as a service, and this attracts the kind of developers you describe.
What's "clean code"?
Capital-C Clean Code? Hell no. This is code that looks clean only on the surface, but in practice it only works on toy projects. Anything big enough is impenetrable for debugging and a performance catastrophe.
Lowercase "clean code" from people who heard the above but never even read the book? What's that anyway? Nine out of ten times, this is just developers putting aesthetic preferences in front of correctness, simplicity and performance.
“Clean” is a horrible qualifier for code. It is either too subjective/broad, or too loaded.
[0]: https://www.computerenhance.com/p/clean-code-horrible-perfor...
This cartoon remains the best visual representation of an industry that seems incapable of doing requirements, testing, documentation, and security.
https://i.kym-cdn.com/photos/images/original/000/475/749/fd8...
IF there is budget for that very often. Otherwise they'll expect you to move on.
Even if you work for yourself doing what you love, even say it's making furniture or whatever, there's always going to be things like customers want the 'wrong' things, or won't pay extra for the nicer exotic material, etc. doing purely what you love as a hobby with no work aspect is always going to be better.
Wings staying attached to the plane in air isn't pumping up the KPIs, fire everyone who wastes time on such irrelevant concerns!
An implicit goal is to grow popular enough to the point that enough programmers collectively agree they should have a say in the "corporate world," such as demanding that we slow down "pumping out" new features and make greater investments in software quality.
> We are the largest indie conferences for low-level programmers. This is your portal to meet with folks into graphics, game engines, kernels, compilers, and more!
Abner, I'd be interested to hear more about what it was like working with Jonathan Blow. (Maybe your project's about page isn't the place to go into it, but possibly here, your personal blog, or private email.)
I'd love to see his reaction to watching the Game Helpin' Squad's tutorial, "Time Travel Understander"!
https://www.youtube.com/watch?v=1fABGyVzVwI
I pointed Will Wright at their SimCity parody tutorial on "Pretend Gas Station", and he loved it!
https://www.youtube.com/watch?v=WPMeWas4kXM
My favorite, which you have to pause to read all the hilarious popup text and chat that goes by quickly, is the Game Helpin' Squad's "World Quester 2" tutorial:
To add to this, the "industry" is very big and fundamentally quite diverse in character.
But right now we're on the tail end of a big surge in growth, and those surges tend to introruce a lot of uniformity in their wake. Processes and practices of the orgs are taken as some part of the secret to their success and are adopted by competitors and newcomers, and after a while everybody-ish doing work adjacent to the booming sectors within the industry are approaching it similarly and procedurally. The focus is on outmaneuvering competing businesses for a slice of the growiing pie, and matters of concern of the craft itself or long-term engineering vision are generally deprioritized.
This is not a permanent condition or a universal one.
All along, there were still people and orgs and departments doing things differently, but they did become harder to spot amidst all the boom chasers.
And as the boom tapers or bursts, with competition having less at stake, even the homogenized orgs and departments start having the headroom to take a second look at their processes, procedures, and priorities and again start to diversify.
It's reasonable to get discouraged if you've only ever seen the kind of orgs you can't stomach anymore, but a little patience can find you with opportunities you're more comfortable with. Some dedicated pavement pounding and deep digging for the orgs that never hopped on the bandwagon can make it happen to.
Different kinds of orgs are out there now, and more will come to look different again in some coming years.
I would add, moving the needle in the short term. A business taking a long term view would care more about quality (reliability, security maintainability).
So the company's shareholders might only want the term to be just long enough to cash out.
What I mean by long term here is more than two or three years.
> So the company's shareholders might only want the term to be just long enough to cash out.
Which means they need to sell to people who think the business has enough of a future for them to cash out. That stretches the terms a bit, but not long enough from the point of view of employees, customers, or what is good of the economy as a while.
Depends on the composition of shareholders too. One thing I recall from my time in investment management was the problem of clients who were reluctant to sell because it would create a capital gains tax liability. At the other extreme are fund managers whose most pressing concern is where they will appear in this year's performance league tables.
From what I know academics in computing fields tend to write high quality software. Not all not Donald Knuth level, but they seem to mostly care about quality.
From my experience, the cultural differences between large corporations, and smaller startups, is night and day.
Often, neither one is functional; but they are dysfunctional, in different ways.
For myself, I was never happy until I was able to helm my own ship. A lot of folks think that this means "hobby programmer," but I don't actually fit that template.
Here's a carved rosewood dragon, from Bali: https://imgur.com/a/nwyGSqT
The entire problem is the vast majority of engineers have an inability to recognise the business function of their output. They live in their own worlds with tunnel vision on minutia. I can’t pin point when this happened but engineering is a complete circus in most companies.
The horrifying thing is there is buy in at senior management, like the engineers have convinced everyone that it should take weeks to deliver some trivial feature, because God forbid they don’t deliver it by using every dogmatic and koolaid driven process they’ve picked up from others over the years.
You work for a business that’s trying to make money, not a software engineering sandbox charity. Of course there needs to be some balance, but boy is it skewed one way for most right now.
Who would have thought this would happens when actual business talks to a business analyst, who talks with a product owner, who talks with the engineer (when a PO proxy didn't manage to squeeze in between them).
So it’s not just “coffee -> code” machine. But the idea that a suit cares about the implementation details, programming languages and such is obviously not true and this community sometimes make it seem as if these things matter. They do to us, engineers, no one else cares much like my wife couldn’t care less about LBJ being better than MJ at basketball (he is not, obviously).
That's fine. The issue comes when you fail to explain how stuff like keeping recent versions of your software or taking some time to fix (at least some of) the bugs moves the needle to people that would never fly a plane that doesn't receive maintenance.
The issue, in economic terms, is that a significant share of our industry's sponsors are the kind of clients that make a market for lemons.
It's hard to practice the art on the side when you already work hard in corporation.
However, I think it's possible to have a bit of fun programming in the corporate world. Besides, the incentives between managements and programmers do overlap. It's not like all managers are stupid. If the codebase is too messy, or lead to too many productions incidents, it makes sense to clean it up and refactor, or use different tools or languages.
OTOH, nowadays I also have to deal with young (and not so young) coders that insist on very baroque designs that don't really help to achieve business goals and actually hinder progress.
It's free to produce, but the cost of running more copied software always increases.
If coupled with hardware, the rising complexity of software makes the hardware more costly to develop and sustain. It may delay the introduction of newer or more valuable hardware features and products.
If this Electron app or container costs me more than it’s worth to me, I don’t run it.
...If they connect the dots.
That just isn't the case nowadays, so you don't know there will be trouble until it occurs at runtime.
I can limit the memory available to ALL the tools I use every day (I only do it for docker and jvm stuff), set priority levels, etc., but it feels very weird for a brand new laptop to hit swap after a few days of uptime.
That was my take, and an unwillingness to compromise on their principles.
Sometimes the compromise may be less money but a more fulfilling role.
Once one reaches a point in their career where they have options this is almost universally true. It's in fact the reason why some jobs pay more, because they need to for people to do them instead of something more fulfilling.
I've had jobs where I thought with a few changes this would be awesome, but eventually realized it's those few differences that mean someone is going to pay me well to do it. Depending on many things, this may be worth it to you or not.
The article didn't mention their financial circumstance, I got the vibe it was someone younger. It read a little disjointed and it's hard to tell whether they sought jobs they believed in or whether they were satisfying an imperative financial need.
Right, but that wasn't what the OP was talking about. In fact the issues they were concerned about were pretty much orthogonal to that. You're trying to make their complaint sound lame and pollyannaish, but really it wasn't.
If you want to do that then build a open source project and a company around it.
I could point out a million people who have made rhyming criticisms of this type before programming even existed. Until those criticisms are met with widespread solid agreement instead of outright hostility or even a resigned "well, it's better than all the alternatives" then nothing will change.
Ive lost count of the number of times Ive seen programmers complain bitterly about e.g. alienation, forever oblivious to the fact that they are rehashing Marx. This post is no exception. When push comes to shove though, 0 of these people would actually dare to call themselves a Marxist.
Companies are there to make money for the owners and thats it, not on some altruistic missions.
I think OP could be better served in academia as long as he keeps greed for money at bay, which some manage better than others over time.
It's a general rule in life that the more 'fun' or 'fulfilling' your job is, the more likely it is to pay peanuts.
What OP needs is enough financial stability and political will that they can do whatever they want. This can be slowly achieved by grinding at a corporation, taking political control and grinding or by violence / threat of violence.
There's of course a lot of bullshit, but you can sort of choose the tradeoff between bullshit and career development/stability. If you're OK with a high chance of never getting a permanent job, in many places you can do practically whatever you want.
And if you e.g. know how to code, you can usually go to the industry churn as a backup when your grant streak runs out.
But yes, in the bigger picture, the latter are the sustainable course of action. There's only so many, or rather frew, grants.
In my personal project I spend a huge amount of time tidying things up, abstracting, cleaning, commenting and that has really started to pay off as the project grew. If I'd let it deteriorate into a random bowl of software stew, I have come to a dead end by now, eternally firefighting instead of progressing.
> if you aren’t moving the needle economically for the company, you’re a liability
yup
Choices made with the current one affect the speed of the next.
Sure you may make a tradeoff between speed and quality in a particular task, but that does not hold over a week or month of work.
It's real. It's what I'm doing at work now.
Every few months we start a new big project. Sometimes they're business-driven (end users can now have many X instead of one X), sometimes they're compliance-driven (we now need to block users who associate with users in blocked countries), sometimes they're tech-debt-driven (migrate from self-managed VMs into a dedicated provider).
We keep finding missing parts we overlooked. Sometimes it's from us having rushed it, other times it's from consultants getting fired while they're working on it, and others struggling to continue the vision in the right direction. Sometimes it's bad tooling - our new managed Kafka host has a mirror-maker tool that doesn't quite mirror properly, or intellij/gradle will flag that a class is missing, but not why (i.e. which dependency is missing!).
- company: a commercial business.
- corporation: a large company or group of companies authorized to act as a single entity and recognized as such in law.
This is indeed the bitter truth I've learned this last decade in the industry.
You're paid to deliver. Whether its efficient, it solved the problem, made any money, ticked some boxes isn't yours to bother or control. Plan tour stuff, do your stuff, be nice to others and sign out at 5.
Don't underdo by writing bad code, or not caring of the downstream consequences of your decisions etc. People do get fired for this.
More important, don't overdo. Don't try to predict how the product evolves and catch those scenarios, don't fight for your obviously better design, don't try to deliver faster, don't try to fix that bug you found while working on something else you are tasked to deliver. Chasing a promotion is one of the worst kind of stress I brought on to myself.
Know the kind of project you're in (high intensity, high growth, mature, next on the chopping block) and act accordingly.
Further, take credit and be seen. Do a demo once every quarter, review people's code, show up for design meetings and ask a question, reply to emails/IM's (that show up before 5pm) quickly, deliver on what you said you will. Be seen as a useful resource but push back (with your actions) on the slightest sign of pressure to deliver.
Finally, always be prepared to land your next job interview in 2 weeks.
Its your workplace. Not your family, nor a body shop.
Being a liability could result in moving the needle, just not the direction the company would prefer.
All of this at the price of the god damn feature never being able to land and my PR staying in limbo for weeks.
But this is just another end of the spectrum I guess.
I started learning programming years ago and never had an inclination to become a software engineer professionally.
Whilst everyone is doomscrolling about AI taking over, I am learning basics and fundamentals of programming and having so much fun.
Its the only activity that gives me flow state these days and actually allows to build something from nothing.
I wish I could pickup the skills faster, but I also realize that I'd be probably miserable...
The corporate world doesn’t give a shit about finesse, abstractions, witty or beautiful code. They care about finding developers who will pump out features to the business requirements. Some human beings in that cog (managers, directors, peers, etc) may allude to enabling developers to actually practice the “art” of programming but the bottom line is if you aren’t moving the needle economically for the company, you’re a liability.
Find comfort in programming outside of the corporate world and practicing the art but don’t expect the “industry” gives a damn about the how or why of programming, mearly the characters we punch onto the screen into cash. Once you come to terms with this, life gets a lot easier, less frustrating and you can actually find fun in the work (albeit, not necessarily “art”).