Hacker News Reader

Comment by wellpast | Hacker News Reader

I never said genius. And "perfectly formed" is not the objective. Tractability is. Go visit companies with medium-sized codebases and find me one that isn't lamenting how difficult it is to grow and maintain it.

I wouldn't consider myself that smart. But I have spent 20 years in this industry with what some might call a sick obsession for understanding how to compose and evolve systems and I've acquired some skills that I believe (1) very much matter to our productivity; and (2) can be mentored and taught, but (3) are not being taught.

My guess is that academy can't teach it because they don't have enough real-world experience behind their pedagogy. And industry can't teach it because it takes quite a while to learn and master -- and what business can afford to do that with their juniors who are just going to leave them in a few years anyway :)

View on HN

I've certainly never worked for a company that did not have a laundry list of complaints about its software, all reasonably successful ones too.

And it usually only takes a couple of beers to draw the same laments from people working in the sort of companies a lot of developers aspire to.

If you think you've acquired a teachable, repeatable set of skills that aren't being taught then it sounds like you've got a gold mine on your hands :) As a relative industry junior (about 10 years) I haven't been introduced to a codebase that wasn't lousy. Certainly all were lousy to one degree or another when I left them, but they served customers all while drawing down the ire of developers (including myself).

> I've certainly never worked for a company that did not have a laundry list of complaints about its software, all reasonably successful ones too.

Either this is a necessary problem (nothing to be done) or this is because of a lack of tools and skills (i.e., our industry is still immature). I believe very strongly in the latter.

> If you think you've acquired a teachable, repeatable set of skills that aren't being taught then it sounds like you've got a gold mine on your hands.

I might some day figure out how to teach this in a larger (non mentoring) scale.

What the skill set looks like and how to acquire it is actually the lesser problem. The harder part is proving to people, quantitatively, the value of the skill set. I know and I think we all know (on some level) the extreme cost of architecturally-unsound software. But it takes a lot of work to learn & master the skill set, so most people bail on doing the work it takes to learn it. (The industry does not reward the growth or reward the mastery enough.)

Only when industry can connect the value of the skill set (and also be able to hire to the skill set) will more people put in the work to acquire it. (The value to industry is enormous but I think it would take some work, research, creative thinking to make the value explicit & tangible and give industry a way to test for the skill set.)

If someone builds me a house I can walk around and test the beams and come up w/ a general idea how well they did and how well the house will withstand the weather. In today's software world, two people with drastically different skill sets can produce a code base -- and it's really hard for the people with the money to see what they've been built and how sound it is.

In my experience, the reason all companies have shitty codebases is because of risk-compensation. When a company does not have a shitty code base, it quickly throws all of its resources into improving the product and user experience for its customers, which increases its market share, revenue, and moat against competitors. This continues until all the new complexity makes the code shitty again, where they stage a cleanup & architectural fixit to be able to make forward progress. If the codebase is not shitty, it means that they're leaving money on the table, and will continue to get shittier until code quality starts costing them money again.

Companies like Google, Microsoft, and Facebook actually do adopt (and often discover) many of the industry best practices. Their codebase is still shitty; the reason is that any cleanliness and rationality in their architecture is quickly eaten up by new features and products that drive the industry forward. As consumers, we see the benefits; as employees, we just muddle along as best as we can.

The only way to break this cycle is for engineers to pay companies instead of getting paid by them. I don't think this is what you had in mind. (Although, some engineers do make this bargain. This is why Haskell/Erlang/Ocaml/Lisp salaries are often lower than they would be for equivalently-skilled Java and C++ engineers: you take a pay cut to work in a language that's actually enjoyable to program in.)

Barring that, the way out is to learn some negotiating skills and at least get paid for putting up with a sucky codebase. If you frame it as "employing my skills will let your other employees implement the features you've been asking for for a year, which will make you $XM in revenue", you can make quite a pretty penny. I know some senior engineers that regularly get paid a couple million in restricted stock for a couple years worth of work.

A startup in general cannot afford to get the best people in the field, unless it's some super sexy bleeding edge tech (which is very rare). So, you are lucky for your first 10 engineers to have one great one, and hopefully no awful ones. And you cobble a codebase together, and the overriding goal is that it isn't totally broken all the time.

Growth first, maintainability last. That's the incentive in a startup.

Unfortunately, in larger companies most managers don't reward improving the codebase unless you are on the platform side, just new shiny new features. Nobody will love you for saying this quarter I removed 2000 lines of shitty code.

I'd love to hear your take on what these skills are. We've all struggled with code bases and some are definitely easier than others. And some people tend to write code that easier to evolve than others.

Start teaching it then?

Reply on news.ycombinator.com