Hacker News Reader

Comment by halfmatthalfcat | Hacker News Reader

It’s not the “programming industry” that OP hates, it’s the “corporate world”. I’ve worked with (and have been) developers who have mismatched expectations on what “the real world” wants out of them.

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”).

View on HN

I think “industry” strongly implies “corporate world”.

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.

I just wanted to make it more explicit since this issue isn't specific to software developers, every career grapples with the "right way" versus the "economically prudent way" in our (US) capitalistic society. That in and of itself isn't bad, take capitalism however you want, but the point is managing expectations to the reality that exists in front of us, not the one you wish it could be.

In my experience, most of the corporate world seems to care more about their aesthetic notions of the Platonic ideal of what code should look like than whether or not it works or whether or not it is efficient. Certainly that's my experience from interviews.

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?

I’ve had the opportunity to work with lots of mechanical engineering corps to date, and I can confidently tell you: Even if they had some platonic ideal, they would never be able to follow through. The mediocrity of their software development practices is… profound. On all levels of the hierarchy. Sure they care about the ideal of sustainable software development, but they just can’t do it.

On the other hand, my employer advertises clean code as a service, and this attracts the kind of developers you describe.

Because code is read more often than written? And clean code is easier to read?

> clean code is easier to read

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.

Wrong. Performance and correctness/cleanness go together. Perhaps you have never tried generating correct code that is ways faster than what you can write by hand.

Once again: what even is “cleanliness”? Are you writing it in lowercase on purpose, or are you unaware of methodologies that share the term? Or are you talking about Uncle Bob’s but refusing to capitalize?

“Clean” is a horrible qualifier for code. It is either too subjective/broad, or too loaded.

OK, I realized it was about something else. I don't follow Uncle Bob, and was referring to some people justifying "unclean"/incorrect shortcuts to gain performance.

I totally agree with you in that regard, "readable" and "performant" often go hand in hand. My gripe is with the "Clean" adjective, that often indicates code that actually isn't readable and is also low performant.

Code is run more than it is read especially if you count users. And so-called "clean" code is a performance disaster[0]. It's also, if that link is an accurate representation of what "clean" code is, a readability disaster. The more readable code, in my opinion anyway, is the version that is also an order of magnitude faster.

[0]: https://www.computerenhance.com/p/clean-code-horrible-perfor...

> first try to make it work to spec

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.

If quick and dirty gets you 10 shots, while slow and beautiful gets you 1, I’d choose quick & dirty any day.

That's not how you build big important, expensive things, though. It all depends on the context.

Do you know that the big expensive thing is what your customers actually need? Do you actually know what your customers need?

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.

Do the customers know what they actually need?

Well if you don’t have a pretty good idea of the problem you’re solving for the customer, you’re much better off trying as many things as you can, quickly and cheaply, to figure out.

It seems that the biggest, most important, and most expensive things are built like that.

Like bridges and skyscrapers?

An order of magnitude is a bit much. I'd say quick and dirty gets you 3 shots, while slow and beautiful gets you 1. And if you succeed, it means the result is dirty/ugly code that must be maintained forever.

Doing it many times tend to be much cleaner than trying to get it right the first time. So fast -> clean, slow -> ugly code, as long as you use the speed to redo and clean things up.

Except the redo and cleanup part never happens.

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.

10 shots facing the wrong direction still gives 10 guaranteed misses. At least make sure which cardinal direction the target is in.

If a large portion of software development is the attempt to discover what is a minimally viable product, then software development is not pure software development. It would be startup business development. That makes real programming to be something like obscure operating system development.

So it's a conflict of names, a matter of proper identification.

> Half the work is figuring out what the customer wants.

And a substantial portion of the rest is telling them why they might be better off asking for something a little different.

I don't see how that's a problem. It's not for everyone, yes, but I like it a lot. Talking directly to the customer allows me to create exactly what the customer needs, without any convoluted process.

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.

Counterpoint: The MVP is usually what ends up in production. If your code is a heap of garbage but chocolate-coated on the outside, you're gonna impress management and they'll want to push it live asap. Then the issues start exploding.

yes, a shitty foundation leads to shitty feature implementation. I've seen this everywhere from startups to Fortune 500 companies. Nobody cares about code quality, except maybe the one self-annointed gatekeeper who thinks he's making a difference and shitting on everyone's PRs delaying features. Get rid of that guy he serves no purpose

That guy keeps everything from collapsing.

Yeah, if the indentation style, variable name capitalization rules, structure of commits, 100% unit test coverage the guy knows is the absolute truth and top priority, a collapse of everything is imminent.

involved conservationists and curators rarely get the recognition they deserve, but sometimes obstructionists are just that

Spoken like a true MBA. Hope I never have to work with you.

People don't care about quality in general unless it affects the bottom line. Not just code quality, but product too. Bugs? Who cares unless it costs us money. Security holes? only a problem if they're exploited... And it costs us money.

Um, yeah, that's… IMHO exactly where an MVP is supposed to end up. The “VP” says that.

> you can then make it right and maybe even fast

IF there is budget for that very often. Otherwise they'll expect you to move on.

I live by three steps when writing software:

1. Get it working.

2. Get it working well.

3. Get it working fast.

Your last sentence reminded me of that.

This is the way to do it. First you want as complete coverage as possible with a unit test showing that the implementation is sound. Then you can try things and refactor for performance, checking as you go that you didn’t break anything.

There ought to be a good spec (i.e. requirements). But it's hard to motivate people to excel without giving them opportunity to grow their talent.

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...

Specs are fickle, vague things. Well written code can accommodate the whims of users and execs alike.

I also tend to find that folks who write quick and dirty code “to spec” leave it riddled with bugs and unhandled corner cases.

> 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.

I may not have communicated this well enough. I wasn't referring to a multi-step process where I hand over the solution in between. I was referring to getting good at making in work, right and fast in one step (at least as far as the customer is concerned).

Many try do it all at once and then end up with… nothing.

Or simpler than that, surprise, work is less fun than hobby.

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.

Because in a hobby you are your own master and in a job someone else is your superior and orders you to do things. If you are lucky many of these things are what you would like to do anyway.

Yeah. It's extremely rare to be able to do exactly and only what you want to do and be able to make money from it. Even the big YouTube celebrities face pressure to make the videos their audience wants to watch. When they go off the rails the views take a nosedive.

> Find comfort in programming outside of the corporate world

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.

I feel this sort of mentality is exactly how you turn into Boeing.

Wings staying attached to the plane in air isn't pumping up the KPIs, fire everyone who wastes time on such irrelevant concerns!

Hope it's okay to self-plug here (seems highly relevant): what you say is a big reason why I organize the Handmade conferences for a living and why they're free of sponsors [0].

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.

[0] https://handmadecities.com/about

This looks interesting, but why is 75% of your landing page your bios? When clicking the link, I definitely didn't have in mind "I wonder who founded this and what their background is". I now know a lot about who organizes this and what their reasons are, but I don't know anything about what it is.

That's the about page. The landing page has more info:

> 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!

Ah, derp, I didn't look at the link, thank you.

The one time I link to the About page instead of the landing... sorry! (I only did it because it mentions the bit about being sponsor-free.)

Nah, it's my fault, I spaced out and didn't read the URL.

To be fair, that's the about page, not the landing page. And their goals and reasons for organizing it are commendable.

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:

https://www.youtube.com/watch?v=0Gy9hJauXns

Shoot me a message (should be in my HN bio)

Corporate? I think ultimately we’re talking about any business here. And a business doesn’t exist to facilitate engineers to go back and forth on a PR for a week, or to fantasise about abstractions all day.

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.

> The entire problem is the vast majority of engineers have an inability to recognise the business function of their output.

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).

I’m sorry but I think it’s cultural, I’ve worked in enough early stage startups where the first engineers are working directly with CXOs, and they’re still firmly living in lala engineering land.

> if you aren’t moving the needle economically for the company, you’re a liability.

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).

Ostensibly that's true, but in the long term we're all dead anyway.

So the company's shareholders might only want the term to be just long enough to cash out.

Most of us will be dead in decades.

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.

Wouldn’t you think this would mean government-made code would be of higher quality (in theory, and ignoring when govt code is made by private contractors)? It seems to be the opposite

Not all developers are equal. Government work pays a third or less what private industry pays. You’re never going to get extreme competence from a government software employee.

Never? You don’t think NSA or Israeli 8200 has preeminent software developers? I think your assumption hinges on people being motivated solely by money. That may be largely generalizable, but I suspect there are relatively large exceptions to that rule.

I think they have the benefit of mystique. I don’t think you’d find their code quality any better than the average. I also think you’d find the same rush to market mania that plagues the rest of the software industry.

Not all competent people are driven by pay. I'd say the most competent usually are not. There are a lot easier and safer ways to get paid well than competence.

Governments are often sort termist too. For politicians next year's election is often what matters. They also have layers of management, in some countries they are frequently moved around so the long term (from any given manager's point of view) is someone else's problem.

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.

I get the politician argument, but politicians aren’t writing software or software requirements, so I don’t think that’s it

From what they wrote, "small startups" are part of that "corporate world."

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.

I vote we bring back artisan. Someone who takes pride in their work, to a form of artistry, and just like in a lot of good art: not overly complicated

Not all artisanal is simple.

Here's a carved rosewood dragon, from Bali: https://imgur.com/a/nwyGSqT

The starving software artist. I like it! :)

> It’s not the “programming industry” that OP hates, it’s the “corporate world”.

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.

> the bottom line is if you aren’t moving the needle economically for the company, you’re a liability.

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 not just the corporate world, it's capitalism in general.

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.

Reading Harry Braverman suitably explains a lot of what is going in programming.

You're not supposed to connect the dots. That could lead to effective reform.

> Find comfort in programming outside of the corporate world and practicing the art

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.

Best job I ever had with regards to coding was for a small family business. I had to meet the requirements, of course, but otherwise I had total liberty.

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.

The corporate world doesn’t give a shit about finesse, abstractions, witty or beautiful code.

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.

That is true. But the way you present the reality of the industry makes it sound like anyone could do anything. That is, obviously, not the case. For example, research lab code usually sucks big time, while other industries might higher standards. Some teams try to make up for lack of personnel by implementing extreme level of automation, in that case you need high quality code, with well thought abstractions and there are only so many engineers who will deliver that.

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).

This. I've been very happily working in a small company and we recently got a new CTO. In a couple of days we will find out which 6 of us are being terminated. Corporate fat trimmings and all that.

Great observation.

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...

And this is general approach, nothing malevolent against IT geeks like some less experienced try to project themselves. They want plumbers also just to keep things running and implement requirements, not have academic discussions about fine art of optimized water flow.

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.

Nope. Academia has a very sad bottom line as well.

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.

Academia can be pretty great if you can live with economic uncertainty, non-unreasonable pay and aren't interested in careerism or that your work has any real impact outside handful of other academics.

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.

The last bit is very true - companies are making money for the owners _and_ to pay the programmer's often relatively high salary.

It's a general rule in life that the more 'fun' or 'fulfilling' your job is, the more likely it is to pay peanuts.

Programming without moving the the needle on _something_ is, ultimately, ugly. Granted, not all needles are worth money. But for the subset of needles that do, you can bang out all the beautiful code you want, and you will get respect for it, in a functional org, even corporate. Abstractions for abstraction sake are frowned upon for good reason.

I was coming to say something very similar. The hard truth is that the society-changing projects this person wants to work on are exceptionally rare, and most work boils down to selling products to consumers. Not that I'm saying this is ideal, but if it were easy to create deep and inspiring work that paid well, everyone would be doing it.

A part of the problem is, no user ever look at codebases. Unlike you da a PCB, make an electrical machine, build a bridge, people see the result. In software people see the UI. Also because copying is free, in PCB for ex. every jumper wire cost you, in software they are for free. So why fixing things truely.

Copying isn't free though. Every front-end application built on Electron or running in a container that duplicates half of the OS stack burns more memory on my computer, forcing earlier upgrades of either the entire machine or RAM with each year that passes.

It's free to produce, but the cost of running more copied software always increases.

But that at least allows the consumer to decide the tradeoff.

If this Electron app or container costs me more than it’s worth to me, I don’t run it.

> But that at least allows the consumer to decide the tradeoff.

...If they connect the dots.

When consumer software still came on physical media, nearly everything advertised the amount of ram and minimum system and cpu requirements necessary to run the software.

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.

So yes, it's free for the dev. The user payes the memory and electricity.

I think there are a number of per-unit costs of software, because your edge cases get tested more frequently. The risk goes up for users finding bugs and incompatible working environments. They demand more unusual features. If successful, your growing user base attracts the attention of competitors.

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.

Yeah, maybe they don't care about abstraction and beautiful code, but they suddenly start caring when technical debt caused by absence of these things starts to hit, but they are too often unable to see that the two are related.

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

Yes, many people present a choice between “code quality” and speed, but this choice is false because tickets are not independent.

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.

> 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.

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!).

Id argue that there is art in figuring out how to continuously churn out features. Its really hard to write your code in such a way it can handle being jerked around, all while not wasting time on what might happen.

"... if you aren't moving the needle economically for the company, you're a liability."

Being a liability could result in moving the needle, just not the direction the company would prefer.

depends on your manager! I just recently told an engineer "well this is more art vs science, so paint the picture anyway you want" and left it to them to write the code the right way.

Your "beautiful" code won't be around if the company isn't around.

If you want to do that then build a open source project and a company around it.

>corporate world

That was my take, and an unwillingness to compromise on their principles.

Sometimes the compromise may be less money but a more fulfilling role.

> 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.

Fair point. Maybe it applies to more experienced people who can afford to pick and choose.

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.

I don't think it's "corporate world", but just capitalism. Non-corporate companies often have thinner margins than corporations and thus skimp on "extras" such as quality, craftsmanship etc. even more.

What is a non-corporate company?

State-owned companies or worker-owned coops come to mind.

Company that's not a corporation. As per dictionary:

- 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.

I wish I had this corporate experience. We focus on finesse, abstractions, witty or beautiful code. I keep being forced to optimise things that we haven't measured, add new lines to places to make the code pretty, rename variables, functions and avoid using Javascript arrays and use the "more performant" sets, etc etc.

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.

Reply on news.ycombinator.com