Very senior developers know things that are not intuitive, but very true. So I'll let you in on a few secrets.

"Good enough is always good enough". You probably want to do more than good enough. Those developers you talked about, probably knew the amount of quality that was actually needed, no more, no less.

Clean code doesn't mean "no bugs" and "good software":

- I've seen very cool, popular, money making games that had terrible code (all in 1 C file for example).

- I've seen a terrible mess of code, that was practically bug free (because it was running for years in production). And have seen that same code refactored to clean code by a junior (who thought he would 'fix things'), and introduced a lot of bugs (because that is just what happens when you write code, even clean one, even by a senior developer).

If you deliver a final product (such as a game for example), that will not need extra features, you can hack stuff in at the end. When you would hack code together at the start, you will shoot yourself in the foot by needing to go through your mess all the time. But when you do this at the end of the project, you can save time by adding in quick hacks. The technical dept that you introduce doesn't need to be paid off. Of course you cannot do this with a long running project. But with a deliverable product go right ahead.

The main thing that you have to consider is this: EVERYTHING IS A TRADE-OFF. I see juniors make this mistake all the time, selecting the best programming language, the best VCS, the best whatever. You know, that 'best' thing also has drawbacks. So it's always about making trade-offs, selecting something despite the drawbacks, because of the benefits.

General rule: if something only has benefits, it's probably because you didn't figure out the drawbacks yet.

How to make the proper trade-offs? Experience ;).

Very true, I agree on all points.

I would add the amount of effort put into designing and polishing any project that you can defend is correct is related to how much future development and use the project will see and how critical the project is for the company.

So, if you want to work o a nice quality project or want to spend a lot of your time on improvements to quality find yourself a project that will either see a lot of future development or a lot of future use or is extremely critical to the business or, best, all of these characteristics.

I see this mistake happen all the time -- people complaining on quality, disparaging previous developers or demanding effort to improve it just for quality sake ("because I just read this book and it can be done better") without reasonable arguments to support from business POV.

Also I see people categorizing all project deficiencies as technical debt where what they should be doing is to first establish what would be reasonable expectation regarding quality and then the debt is only what would be absolutely necessary to reach that reasonable expectation.

So for example, if you make a small app that will not reasonably see a lot of future development but is critical to work reliably in production (and it isn't) your debt would most likely be centered around making the application reliable enough and probably not around making the code nice (as long as it isn't preventing makeing the application reliable).

> Clean code doesn't mean "no bugs" and "good software"

This gets missed too often: clean interfaces are important, whether it's a UI or an API. Clean code? It depends.

I once interviewed a dev who had all the right answers when it came to software development practices, TDD, etc, but when we looked at the product he was working on, the UX was a stuttering mess.

I don't care what your code looks like if you did not achieve a good end-product.

> the UX was a stuttering mess.

Is that a good metric to judge a developer, though? Good UX requires either formal training in the field, or a very gifted individual. In my opinion it has very little to do with the quality of either the code or the developer.

The UX design is not something I would judge someone on, but UX as a function of UI performance definitely is. If the UI is hitching, non-responsive, or getting into strange and incomprehensible states without giving me any indication how or why, I place the fault of that on the developer who implemented it.

It is a very good metric.

To have baseline UX awareness is crucial for every developer on any team that sets out to build a great product, just like any effective designer has to be aware of physical limitations of his design space (for example speed of light, bandwidth)

If your UX designers job is to point out that responsive UI is indeed important for your product, he is not actually doing UX design and you are likely in deep trouble.

You're assuming all products are apps or websites or something with a GUI. A product could be a library, or an OS kernel, or a web API, or any number of things, where knowledge of how to make a GUI with a good UX is completely irrelevant; or the programmer could be working on a very technical part; the engineers working on, say, Safari to optimize the javascript engine's performance similarly don't need any knowledge of what good UX means for a graphical interface.

Apple and Google shouldn't fire their best compiler/JIT writers just because they write lousy GUIs.

There's a UX for those things too. The users would be the consumers of the API.

Obviously, but the kind of UX discussed here is obviously that of graphical applications; nobody would say that a web API's or a compiler's UX is a "stuttering mess".

Basically everything computer that interfaces with humans is graphical. That doesn't mean it's in the designers domain to fix.

A designer is not responsible for making sure that the implementation of their design runs at stutter free at 60fps in a browser -- that is an engineers job. If the engineer who implements such a design is insensitive to these things and needs convincing that it's important to not have the implementation not stutter, jerk or jank you are never gonna get good results.

Not necessarily, but good developers need to be thinking about their upstreams and downstreams. This is often uncomfortable because a developer personality often wants to know all the minute details and not have to worry about areas outside their core competence, but you can't build large scale software without at least a critical mass of developers thinking big picture. UX in particular depends on the task at hand, but if it's a consumer product and you're working fairly close to the surface (client or API tier) then yeah I'd expect some awareness of UX.

> don't care what your code looks like if you did not achieve a good end-product.

I do care if your code is a mess if other engineers have to maintain it.

I'm not saying clean code is not desirable. Code which is easy to maintain and modify is absolutely better than messy code.

My point is that "good code" should be prioritized behind a good product. The purpose of code is to deliver a product, not to be well-factored or to embody certain principals. If your product is bad, your code is already categorically bad, no matter how beautiful it is.

But it's really difficult to make a good product and good product experience on a messy code base. Quality code leads to better product IMHO. (of course good quality code base can still suffer from badly designed UX)

The devil is in the details. Sure, if your codebase is systemically messy, it's probably going to take forever to get anything done, and you will probably end up with bugs in the final product.

But what if you have a component here or there with well defined, well tested interfaces, but internally it's a bit of a mess? Or what if you hack together a proof-of-concept for a new feature to get it out the door and see what users do with it before investing a lot of time in making it perfect? Those kinds of things can help your organization move faster.

As with most things, clean vs messy code is not a binary. It's the sum of a lot of individual value judgements about when it's pragmatic to focus on code quality.

Without fully qualifying what “easier”, “good product”, and “good experience” mean as well as delineating project constraints such as time, business value, and life it’s not possible to truly have this discussion.

Even so, I am inclined to argue that in most cases the exact opposite is true. That is, it is actually “easier” to create a “good product” with a messy codebase, because in most cases “easier” and “good product” are understood by primary stakeholders to mean business value at this moment.

I would love to do the following experiment:

- One coder writes his product with a high quality code base.

- Another coder sits next to 3 users of his product, and hacks stuff in as fast as possible.

I would bet on the 2nd one for having the better user interface.

Agree with all points. Here's another - depending on the size of the shop and the population of users it will be delivered to, there are trade-offs that must be made as you go towards zero on both of those axes. For example, if you have two developers delivering in-house apps to 250 end-users in a SMB company, then the answer is never, "That will take two years and $2M." It is, "We can have that for you in a month," and then you deal later with things that necessarily got skipped. Sometimes it means refactoring and bug fixing, if the pain points to the business are large enough. Sometimes that may mean reaching into a database to fix data that is caused by a complex bug that only manifests itself once a year and isn't worth fixing outright (because there are other things you're working on now). That outlook is probably way to "Realpolitik" for the purists, but it is reality in small shops (which still do exist).

> General rule: if something only has benefits, it's probably because you didn't figure out the drawbacks yet.

And that, of course, has it's exceptions too. Non-optimized stuff exist, and everything that isn't on the optimum line can be improved in some way without drawbacks. Besides, the optimum line is always moving.

So you optimized some code, cool!

- How certain are you that you didn't introduce a bug? - Is it also running faster on this exotic platform that we still need to support? - Did it involve API changes? - Do we need to put this into production now, or wait for the next optimization to save some time? - How much time did we spend on this? Was there something else that would have made a bigger impact?

In theory you can improve things without drawbacks, but in practice you always have to make the right trade-offs.

Just to point, my comment wasn't about code optimization (but can apply to it too).

>- I've seen very cool, popular, money making games that had terrible code (all in 1 C file for example).

Are you sure that wasn't an optimization to get "LTO" with a non-LTO linker?

No, in that case you would #include all your .c files in one .c file and compile that for release, but would otherwise work in the usual manner. CMake actually has builtin support for doing just that.

That would be a nicer way to do it, but it doesn't contradict what I said.

Any halfway decent developer that wants single file optimization but doesn't want to author the source code in one file will do this.

See "Unity build".

I talked to the developer, and it was him who mentioned this, and he was not proud of that part ;).

There is a very real truth to what you say, and I don't believe it is bad.

We don't want golden-polished software. Software that only just does its job, makes the company money, pays the bills, and allows for future improvements where possible/necessary. Lean and mean, then refine (if the bills have been paid).

The distinction has to be made between good software and well-written software. It is very possible to have well-written bad software and awfully-written good software.

I think realising this, is what makes a junior into a senior. Having the confidence to not always do what that little birdy in your head says :)

Customers buy software that solves problems, therefore good software solves problems. Customers buy good software, not well written software. These are not always mutually exclusive.

For a long time, I kept pushing deadlines because I wanted to write things the "right way". At the end a code that doesn't reach its destination on time or doesn't do what it should be doing is useless, no matter how well written. A good engineer knows when to obsess over code quality and when to look the other way.

Agree. It helps to cut your software-chops or steer yourself into an industry where software is an overhead, rather than the main product (said in the best possible manner).

For example, controller software attached to a turbine engine. What I said above is especially true in those scenarios and is actually quite folly to do more than necessary in the name of software perfection. Plus unnecessary complication hurts brains :)

It depends so much on what you're doing. I've been in situations where junior or mid level devs spend a ridiculous amount of time on details that add almost no business value even in the long term. The best developers from the employer pov understand, depending on the project, which level is good enough.

>And the end-users in many niche industries are used to being shipped garbage, so they're just as happy too.

I'm one of the end-users of many terrible B2B products. I'm not happy with them, it's just that the department that buys the software from IBM & Co. doesn't use it. They don't care. But it costs a lot of money in the long run because of bugs and slowness.

Pretty much my experience too. I don't think it's ever been worth the time or effort to spend time on writing quality software, the people that smash it out quickly are the ones rewarded.

I'm starting to feel like the whole movement for 'software craftsmanship' is making a lot of developers miserable. It's maybe better for them to realise they are not artisans, they are bricklayers. To focus that creative energy on their own projects rather than getting burnt out fighting their managers over writing 'good software'.

I don't think you can turn it off like that. There are no Michaelangelos spending their day slapping emulsion on drywall.

Opportunity is not evenly distributed.

>I'm starting to feel like the whole movement for 'software craftsmanship' is making a lot of developers miserable.

Not as miserable as working on some 7 year old system hacked together without any craftsmanship. Plus if its a long term project the maintenance costs must spiral.

I think the point is that it's better to work on some 7 year old system hacked together without any craftsmanship with the belief that craftsmanship is nonsense and spaghetti code is a legitimate design pattern, than to work on it knowing there is a better way to design software.

The end users aren't happy, they mostly hate the crap that is foisted on them.

Very much this. People have incredibly low expectations of software, so of course the software industry feels no need to push for higher quality.

Generally business considerations >> user happiness.

Software is primarily shipped to make money. If a shitshow product - it's not hard to name a few - makes money, there is no business feedback loop which will raise quality.

Senior devs tend to justify this on the basis of experience, and management justifies it on the basis of shareholder value.

In reality it's just cheap, shoddy, dispiriting, and cynical. In a mature industry developers would be able to take pride in making end users happy [1], as opposed to making them frustrated and enraged.

[1] Not the same goal as impressing developer peers.

They hate it, but they pay for it.

Perhaps you could make something they love instead, but if the production then costs 10x more, and they are only willing to pay 2x more, it does not make sense economically.

I'm reminded of, of all things, WW2 tanks.

The Russians built a huge volume of very low-quality tanks, expected to go for only a few hundred miles, and to win through superior numbers. Their crews were poorly trained. The designers suggested easy-win improvements, but the brass blocked the changes as it would have impacted production rates.

The Germans built the best-engineered tank the world had ever seen, but its design tradeoffs made it ineffective, and it arrived too late in the war.

Now for a different context: consider Russian cars vs German cars.

Also Russian fighter jets vs American/NATO, in the 70s-90s timeframe for example mostly. I love the excercise of comparing the 2 design styles: completetly different aproaches to the same problem, both very effective and elegant. Just looking at the surface (copckits) of it gives one a very good impression of the differences.

Really a lot of russian vs american style examples.

Also technical (engineering) books for example. Generally russian books where a lot more condensed, raw, pure numbers/formulae etc. American school was a lot more colorful, pictures, graphics, plots, diagrams. There were people that liked better the russian style, however I think the "prettier" one has prevailed.

Interesting subject I think.

German cars still suffer from some of the same poor engineering instincts that handicapped their tanks and aircraft in WW2: an emphasis on complex designs, unproven innovations, and theoretical or lab-measured performance rather than simplicity and empirically tested performance and reliability.

Worse is better.

"worse is better" is worse

Nah they're not happy, they're just trained to think it's how things have to be.

You know that and I know that, but often it's easier said than done to convince them of it. I've had users get indignant because I dared criticise their favourite enterprise bloatware like I insulted their mothers. Even as they themselves were struggling with some misfeature keeping them from doing their actual work.

But it does mean that it's easy to exceed their expectations, for example by making the browser back button take the user back to the previous view instead of crashing the entire user session. I tend to try to justify spending time solving technical debt by making development of new dazzling features faster and cheaper, but as long as the users (and more importantly their managers) are sufficiently dazzled if you only throw them a pittance once in a while, that becomes hard to sell.

I think I'm getting to that point as well. I've written some very tidy code back when (~5-10 years ago), but nowadays I'm more and more thinking it doesn't really matter - more than one of the projects I've spent months and years of my life on have already been replaced. Not because it wasn't good, just because an alternative was better for that company (like when they replaced some big java enterprise CMS with just some Wordpress instances recently).

Have you ever worked maintenance programming on some legacy software?

Disclosure: small-ish company (~100 employees) in France

You know, I kind of went through the same questioning: at my current company we have an employee that has his niche/historical role on one of the key infrastructure of our product.

The guys works from his home and whatever hours, commits 300+ lines per commit (90% of which is unrelated to the commit name, just commenting things or uncommenting others). The code is a spagetti of if else if else, it has monstruous "client specific" code (like: if the current client is this guy, then do that, otherwise for all other clients do this).

There's even a load of "if the program runs in test, answer what the test expects, otherwise in prod send something else".

Every time I look at the commit tree (a balance of wanting to have fun and wanting to see what is going on), I'm in horror. The guy rewrote the java.lang.string, the java.lang.date, and some other base classe of the language to incorporate his own version of the Date handling.

Fun fact, at one point his date parsing code "wasn't happy with october"... why? because October contains the letter 'T', and he botched his ISO date parsing (format: YYYY-MM-DDTHH:mm:ss) by checking the presense of the letter T..

I have many many stories of him commiting some bad code, only to spend 12h in a row trying frantically to correct the bug by adding ifs and elses.

The last time I looked at his code, he was rewriting a huffman compression algorithm by himself (NIH syndrome) to compress his on disk data. Complete with loads of code to handle per-bit operations that he wrote b y himself instead of relying on a battle-proof library.

Management-wise, they accept his behavior because this guy, working from his own home, often can work at scandalous hours and be on the bridge when he pushes a botched version to production at 2AM. At the time of this comment, his last 4 commits on master are at the following time: 08:57PM, 10:40PM, 12:11PM, 01:02AM

I know I'm venting hard, but this guy is probably be the best paid engineer of the company, he is a huge liability IMO, and is present at all-hands meeting maybe once a month. So yeah, why bother coding great code, making sure that your tests and CI are green, when some other guy with a bit more history in the company can get away with doing shitty work and having poor life balance, as long as he shows "commitment" when he botches his software releases.

This is really some life-long questioning of mine: should I care about things or should I focus on politics and disregard others. Aren't those on top of the pyramid the more "sharky" people that climbed the ladder not by pure skill but by showing the appropriate (bad) behavior when needed and correctly compartimentalized their own questions about ethics and got away ?

I replaced that guy at my company (similar size) and a year in I'm barely scratching the surface of the horror, a lot of the time I end up putting a safe interface in front of it and a big note saying fix this at some point.

It's nor even that the code is bad (and it is) it's that he couldn't think straight, the business logic is all insane as well.

Still boss hired me to sort it out and the time scale is measured in years (week is a mix of new stuff and fixing old stuff).

Typical performance improvement is two orders of magnitude.

When I started it took 70s to search for a quote.

Now it takes 200ms and mine includes the line details on the quote in a easy to eyeball format.

My boss seems happy at least.

It really depends on what type of business youre in for the quality to matter. If you were say, writing a real time data infrastructure platform for a whole company, or something else related to distributed systems, then the code needs to be good. If you are working on CRUD line of business software with some complexity, then it can be garbage. In general, the closer the code approaches to actual computer science problems (and this is out of necessity), then the greater the need for good code. Few businesses have this requirement.

It's funny how when you make a bug and then stay awake at 1AM to fix it in production, the managers will mostly remember the latter.

Now that I'm thinking about it... do the managers actually know the bug was caused by his "programming style"? Because, if they are under impression that he is fixing other people's mistakes... then it would make sense to pay him better than the rest.

> This is really some life-long questioning of mine: should I care about things or should I focus on politics

I guess you need both; and the exact proportion depends on the company.

> Aren't those on top of the pyramid the more "sharky" people that climbed the ladder not by pure skill ...

This already assumes that those on the top have climbed the ladder. As opposed to already starting somewhere higher than you will ever get.

I've worked with people like that, not exactly on my team. Managers loved him because he was always "committed", working late hours to fix bugs his own botched code created.

I bet the cost/benefit for the company is positive, and as long the clients are happy and paying, how this guy works is irrelevant. he was rewriting a huffman compression algorithm by himself because he's bored and he wants to learn and experiment. I bet is not a good life he's living. There's a great disorder in working from your home at odd hours, it's not healthy. He would be happier working normal, fixed hours, and with a manager to guide him.

> There's a great disorder in working from your home at odd hours, it's not healthy

I'd be curious in hearing you elaborate on this. I've been in a WFH setup like this for about 4 months, and while I enjoy it right now I do wonder if it'll be something I might regret after 2-3 years on this schedule.

My primary reasons for working like this are that: 1. I hate being in the corporate office environment, it feels very artificial and constraining 2. I tend to have my most productive coding sessions very late at night anyway

I did the WFH for a year, and while the freedom is enjoyable it is very easy to slip into working very late going into 'hermit mode'. You have to be very diligent in training yourself to be productive during normal hours so you can be social in the evening.

My new situation is categorized as flexible office hours. I go into the office 2-3 days a week, enjoy good rapport with the people I work with, then WFH on Mondays and Fridays (typically). I find this to be a good balance - I have enough structure Tuesday to Thursday that I can continue this trend Monday and Friday.

If you are valuable enough or underpaid then make everyone around suffer when they force you to work on these tasks. People will learn and you'll have easier time.

Beautiful!

I would pay for a book with more anectotes of kafkaesque, nightmarish visions of horrendous programs.

I could spend a year writing blog posts on the one I inherited :)

>just spew large quantities of low-quality code that made the managers just as happy

Honestly this is my biggest disappointment as I get better as an engineer. No one except me seems to bother about simplicity, readability, maintainability (Ok a few of my colleagues do).

Seems like you kind of answered your own question. :)

if you care about people then yes. if you don't then no.