I learned way more from him than I ever have from the kind of peers who have opinions about how to structure every line of code.
Nobody can quantify 'good-enough code' but everyone can quantify meeting a deadline.
How much engineering is anyone really doing anyhow - or are we calling using React to build yet another set of forms users fill out with some error handling engineering nowadays? :)
Ultimately it gets done faster than it would if the whole team was my personality, but with higher quality than if the whole team was their personality.
This approach probably works out because you have senior engineers laying out a lot of the core structure and architecture for how things built. There's a tendency for newer people to tacitly adopt patterns that already exist and replicate.
However, this approach can be really problematic when you have a team that's primarily newer engineers. I've seen it multiple times and it's always the same result - productivity almost grinds to a halt over time because there are so many problems in the code base. The worst example I saw was switching teams and seeing the team velocity. We measured all the work in story points and used the exact same task as a baseline story point. The previous team with mostly senior engineers, a point took .5 days. With the new team that was started by all fresh grad engineers, a story point took a minimum of 3 days and usually bumped up to 4 days. This velocity lasted multiple years, even when the team had a much more balanced spread of senior, mid-level, and fresh grad engineers.
I've often said the difference between a senior and a junior isn't writing software successfully, it's writing software that's maintainable 5 years down the road. The only way to learn that skill is to deal with a project over years and learn the pain points that aren't immediately obvious w/i the first 18 months.
Undelivered pretty code doesn't deliver any business value.
Same applies to 100% code coverage that isn't running on customers computers.
There's probably an optimum somewhere in the middle of each philosophy, but it's certainly not close to either extreme.
Reasonable code isn’t technical debt. The obvious tipping point is when spending X hours now likey saves people less than X hours in the future. Which unfortunately depends a great deal on the details of the actual project involved and therefore requires experience not some universal methodology.
It is a balance that needs to be learnt, and a trait of seniority.
This philosophy less relevant in larger companies with more engineers also.
I get your point, I just question the specific example.
Make it work and make it as straightforward as possible.
The hardest part of making anything is getting to the minimal viable product. Editing and refining and upgrading aren’t necessarily easy, but they are typically less daunting than staring at a blank page that you need to fill.
So you better not tie your self worth to the quality of the things you produce.
You can go into some interviews, say you write code just good enough to ship, and that will be a red flag to them.
You have to choose your tribe on this issue and be comfortable with the other tribe hating your style.
See also: https://apenwarr.ca/log/20211024 (Wants, needs, and chasm crossing).
In the company I used to work at, code quality was a huge deal. I think, destructively so.
Nevertheless, I exercise pretty extreme code quality in my work (see for yourself[0]). It's long reached the state of "muscle memory," and I work very quickly.
As I am the person that most frequently has to go back and fix the code I write (I eat my own dog food), I write code that is what I want to see, when revisiting, six months later.
On another note, this industry considers six years to be "senior." I find that interesting.
I'd say maintain good code quality on your own project is much easier than within a team. It's like living in a house with different people: not everybody has the same standard regarding keeping the place tidy and clean, and compromises have to be made.
This was one of the biggest pain point for me, moving from my own personal projects to working with other people.
Managers often neglect to take team overhead seriously.
So, yeah, the OP doesn't even mention code quality. The comments do. That's ok. It's just how the site works.
> Variable names are important because they communicate to the reader what’s happening. That’s their only job in code, so it’s important to name them well. Long verbose names don't cost anything:
The conversations aren't about code quality -- they're about a finer point of it and in concrete terms rather than in beginner terms.
I'll play devil's advocate and argue that this could just be the code equivalent of privatizing the benefits while socializing the costs. You mention that your team writes code without explicit discussion of its quality. The benefits of that choice are front-loaded, while the costs of that choice won't be apparent until later. Furthermore, the team members who have to pay those costs may not even be the current team members - it may actually be those on the team months or years from now, after the original code authors have left for greener pastures.
So it may be too early to declare that your choice was a successful one. As the article mentions, code is read much more often than it's written.
Functions are regularly 50+ lines with 10+ logical expressions. Most features are written as single classes with 3k-5k lines. Everything is written imperatively (that 50 line function declares a variable at the top and mutates it 10 times as it works through the control flow.) The same magic values are redeclared multiple times through the codebase instead of using a shared constant. His PRs are usually 3k-5k lines and take hours to work through. etc. etc
His code takes way more effort to understand and takes orders of magnitudes longer to change than it reasonably should.
Also his code works. It generally does what its supposed to do, covers edge cases, and is reliable. He also delivers with decent speed, but all that saved time is being pushed on the poor sap who has to work with the code next.
I think quality in terms of correctness is always the target, and performance usually has a target SLA.
The thing good and bad code have in common is the fact that it needs to updated. Either for bugs or changing business need.
So focusing on the operational side becomes much more important. Code is the trivial part. Creating systems that can be modified reliably is the hard part.
I rather have ownership over a "poorly" coded service with proper ci/cd, integration tests, monitoring, and a team that reasons about and follows strong operational processes, rather than some beautiful code in a vacuum.
Making any of that work for spaghetti is rough, since it lacks the boundaries and entry points those things rely on. And even if you ostensibly have it for “bad” code, it tends to be fragile and unreliable. (As my many, many overnight pages have shown.)
Of course, that may be different perceptions of “good”.
A common refrain is that if you're not looking at code you wrote 6 months ago and thinking it's poor quality then you're not growing as a developer.
This is probably true for the first few years of a developers career, but there are only so many ways to build an authentication system (for example).
At some point your improvements are at the design and systems level. You start to develop a nose for what can be problematic and how to avoid it. Linus Torvalds referred to it as 'taste'.
And as you said, often times there are organizational and procedural challenges that have a much larger effect on the success of a project than purely code concerns. Not that code concerns are irrelevant, but good enough is good enough, there's generally an expectation that developers can read code. In the same way there's an expectation that readers of a novel are at the literacy level to understand novels. No one would blame James Clavell if a 5th grader couldn't understand Shogun, even though it's true that Shogun could certainly be improved from a prose perspective.
You can cut a lot of corners, as long as you don't paint yourself into a corner. OTOH an extra hour not spent today on doing the right thing may and will result in extra weeks and extra thousands of dollars spent in a few months.
I recently started to work in a team of very senior engineers (with relatively little experience) and what I've noticed is that code quality is rarely mentioned. Everybody write "good enough" code and there's never much discussion around code quality (occasionally a few remarks in code reviews) or design.
Generally, there's very little bikeshedding on code quality and that kind of things. People are pragmatic and wants to get the work done. It also means there are trade-offs regarding code quality (also dictated by management and pressure to deliver).
The challenges are elsewhere. Prioritising, communication, relationships with colleagues, setting up roadmaps and milestones, proposing designs, solving various challenges.
Generally, I found software engineering is less and less about writing code. I'm impressed how my colleagues are good at everything. Fluent in most programming paradigms, able to debug complex production issues, do low level performance analysis and so on...