Comment by leto_ii | Hacker News Reader

Comment by leto_ii | Hacker News Reader

Many of the points made in the article seem pertinent to me, however I think thinking in terms of discrete levels of seniority is counterproductive. I also think that there isn't a single dimension of seniority that we should talk about.

To give a precise example, in my previous job we had very hierarchically senior people who understood the industry and the business side very well and of course knew the company's platform very well. Oh the other hand, strictly in terms of technical competence I think they lacked a lot of the basic mental framework. Their code was atrocious (core code in classes of 1000+ lines with no documentation or tests, lots of copy-paste), their choice of technology and methodology parochial and antiquated (think Java 5-6, Ibatis in 2016 + a lot of in-house built stuff, no code reviews, no QA etc.).

This kind of people in some ways would rank as competent architects and in some other ways as fitting the good old adage "20 years of experience - the same year repeated 20 times".

It’s also illustrating that we engineers love to nitpick over stuff that ultimately doesn’t matter all that much. You know what’s way more important than short functions and programming platitudes like DRY? Understanding the business, system architecture, and how to deliver fast in the context of what’s already built.

Well engineers love to nitpick over stuff that we know will bite us in the ass in a few years. The most wonderfully architected set of business rules is of little help if it takes weeks to debug and it's impossible to refactor and add new features in future because no one knows how the code really works (and the guy who did it left long ago), it's untested and unreadable. Lots of great projects died slow deaths because of this.

s/know/think

See also yagni, premature optimization, etc, etc

Yeah those are all useful rules of thumb but I doubt anybody is gonna tell you that the point of those is that you should just not give a damn about anything besides whether your code can tick off the AC of a ticket.

My point is that a lot of engineers freak out about things they read a Facebook engineering blog post about, and are "engineering" a crazy complex system for months to handle non-facebook volumes of traffic. They then reassure themselves by valuing the ideological purity of their design over the months salary they wasted on building their Sistine chapel of REST. This is mid-level engineers all day, every day.

Yes, sure, that sucks, but you need some kind of balance, because sometimes you dig a hole that's so deep it's hard to get out of. Surely part of being "senior" is having some sense of what kind of abstractions and optimizations are worth making up-front and which can be saved for when they become necessary.

That's not at all what I said. Engineering discipline is important.

This deserves more upvotes. I have met so many engineers who do themselves a disservice by overvaluing the esoteric bits of code that nobody but their team will ever see. The business doesn't care as long as it works, and soon. Which isn't to say that you shouldn't sometimes sweat the small stuff, but you always have to remember that you're working for a business.

Only if you don't care about long-term. Those things are not "platitudes", those are lessons learned from the experience keeping large systems maintainable.

(that said, there are plenty of systems where long-term term does not really matter, as well as cases when good rules are taken to absurd levels)

You picked the easiest strawmen out of his examples to knock down in short funtions and DRY. The other examples were, no QA, no code reviews, which are things that I have seen first hand, combined with the other complains, to code that is always in a half broken state. The code is very difficult to change so you spend all of your time on support cases. Re-writes have their own pitfalls. Ultimately, developer retention and hiring suffer because no one wants to work on these products. The institutional knowledge leaves through attrition and it takes too long for new developers to learn to be productive in the code base. Eventually the quality of the product declines until customers leave. So, even highly profitable products die because of poor engineering practices. There are certainly engineers that get caught up in know-it-all platitudes, but I've personally seen more profitable products fail because of poor engineering practices than good engineering practices fail because of poor business sense. YMMV, but in my experience, good engineering is more rare than good business ideas.

Woah my experience is completely different. I've never seen a product fail because of poor engineering practices. And I've seen plenty fail because of business issues.

I've worked mostly on enterprise software, many of which had awful code bases but we're wildly profitable.

My best bosses and I think every mentor I've ever had (some were both) talked about what they value, where they want us to be, instead of micromanaging us on how to get there.

Some business strategies are antagonistic to this sort of work, others are in effect the inverse (as in, doing the exact opposite).

I think the saddest 'joke' I tell is that I watched our industry, during the XP era, look at the numbers and decide that most of our problems come in during the requirements phase, and then instead of tackling that problem, we spent the next twenty years making sure our side of the house was in order (didn't work out that great, did it?).

Why did we do that? Did we think we were going to shame our business complements into doing better? Some of these positions actively seek out people who don't experience shame the way the rest of us do.

In theory, XP's theory in particular, fast iterations split up the business decisions over a long time, so the wreck happens in slow motion and more intervention, talking, and concrete examples are available to improve the quality of dialog.

Then Scrum gets co-opted by the business people, and now the business side does, indeed, have more time to think, and what have they done with that time? Found ways to give the developers less time to think. Oops.

I'll agree with you on that.

Take PHP as an example. I'd say from a technical perspective not many people would go with it from a technical standpoint but we can't ignore that massive companies like FB for example were build on that (no matter if they grew out of it at a later date).

> I've never seen a product fail because of poor engineering practices.

I've seen plenty of things fail due to extremely high costs to develop basic features with few enough bugs to satisfy customers. That is mostly the result of bad engineering practices, like choosing C++ instead of PHP for your web servers, or just plainly having bad engineers who don't know how to build a big project.

What kills those products is not the bad code itself, it's the side-effects piling up: added dev expanses, lagging behind the competition in adding new features, performance problems as app grows, etc. Badly written code is simply more expensive to maintain and improve. I guess it's less of an issue if you have a very profitable product and/or enterprise clients who are much more tolerable to things like the simplest customization taking weeks to finish, integrations that are complicated and cost thousands and thousands of dollars, etc. For startups and smaller businesses that are tight on dev budgets it's much bigger of an issue.

> Ultimately, developer retention and hiring suffer because no one wants to work on these products.

This was/is indeed the case for that organization.

> The institutional knowledge leaves through attrition

They have addressed this problem by simply silo-ing knowledge with a few key people who were very well compensated (think 10's of millions in stocks). These guys (the senior developers in my example) would only give out knowledge in bits and pieces, enough for you to do your job, but not much more.

> Eventually the quality of the product declines until customers leave.

I think more than the product becoming worse, it will simply be out-competed by better products. This will happen slowly though. By the time it does everybody who's anybody will have cashed in and moved on.

> would only give out knowledge in bits and pieces, enough for you to do your job, but not much more.

I'm curious as to how they would do this. I ask because I've seen both sides: as someone new to the company trying to understand the lay of the land and being frustrated at the lack of documentation, and on the other hand being asked for more documentation about things but not having the time to do it because of being pulled into doing other things and simply not having the time.

It also seems like most junior (for lack of a better word) developers often don't read documentation anyways, so it seems like a waste of time to go above and beyond to write docs.

HOWEVER. It is completely and totally inexcusable to build products without code review, regardless of how senior you might be. If its a spike or POC, fine. But if you're going to productionize it... you better have someone else review your code. I did see this happen and its a horrible problem: these "Senior" devs build totally unstable systems and offload them to another team to maintain; the poor team then spends most of its time putting out fires...

> most junior (for lack of a better word) developers often don't read documentation anyways

Though there are many other factors that contribute to excess reliance on tribal knowledge, I consider this a huge contributor to "bits and pieces" knowledge transfer. There are many people who ask others for help immediately upon encountering a problem, and they (as a group) reliably ask the same basic questions over and over. Many ask the same questions more than once, for years on end!

My honest answer to these questions is "fuck off, read the docs and don't just dump error strings into chat and rely on other people to do your job for you. Come back if you're still stuck after reading the docs with an explanation of what you tried." However, these questions are often asked in public fora, and I feel that I'll gain a reputation of being surly and not a team player if I respond earnestly: I'll give a "bits and pieces" response that probably answers the question without explaining my thought process or giving context with the aim of making the question asker go away as quickly as possible. I wish I knew how to effectively guide people into the habit of trying to find their own answers first without coming off like an asshole, but figuring that out is harder than just providing the answer.

There are, of course, plenty of things that /are/ poorly-documented. Giving bits and pieces answers for those /is/ harmful. But the same question pattern happens with public tools that are extensively documented (the Python standard library or Kubernetes, for example), and it's draining to babysit people that never learned how to, well, learn.

I have faced the same dilemma and don’t have a good solution either. An interesting twist is that people that ask basic questions that can be looked up then “DM” me on slack. My approach has been to ignore such questions; often I legitimately lose track of them anyways, but I don’t like the approach simply because it seems anti social. Then again I am only a human; it’s hard to provide one on one assistance to everyone that asks.

> I'm curious as to how they would do this.

No documentation, testing or code reviews, selective knowledge sharing (only to some people at some times, the others might get yelled at), code that is not easy to understand on its own (not impossible of course, just hard enough that you won't bother understanding unless you really had to).

Big decisions were not really discussed with anybody except a select few. The regular developer would simply have things communicated to them e.g. from today we're using Git instead of Subversion, from next week we're doing weekly instead of monthly releases etc.

Of course, if you were persistent and really interested you would get to know more about the platform. It's just that things were made hard enough that most people wouldn't really want to do it.

We discount logistics a lot when we have conversations like this.

One speaker years back (possibly before Scrum darkened our doors) disagreed with the Tech Debt analogy and asserted that we're talking about wear and tear.

At the end of the day, making a change that doesn't cause any strong feelings is much cheaper than one that does. A lot of these supposedly aesthetic, nitpicking conversations are about not feeling a sense of dread when you have to look at a piece of code. I want to say that 'dread is the precursor to procrastination," but I think there are some psychologists who want to claim that procrastination is dread.

If you've ever seen anyone argue vehemently about how they can't do two 4 hour tasks in a day, it's probably because they know that one of those tasks is going to wipe them out and they'll spend the rest of the day recuperating, doing menial work or even goofing off.

If I get to control the narrative for a project, which isn't often, then eventually I will remember the roads that have always worked for my teams. That projects go better when we feel like we're incrementally getting more productive all the time, instead of slowly calcifying. That our tools require progressively less vigilance, our code becomes less scary and we become less afraid of it. We talk about what we can productively accomplish instead of what's theoretically possible to pull off. We leverage that to throw in cheap features people didn't even know they wanted, or solve problems they did not know they have (twenty minutes watching a user is more informative than days of interviews and a mountain of surveys).

That last bit may be more important than even I realize. How proud can you be of something you were ordered to do by someone you don't even interact with every day? I've never really thought of it that way before but I sure am now...

Yes, but what if your failure on those other fronts start to compromise the timely delivery of correct software that performs acceptably?

> You know what’s way more important than short functions and programming platitudes like DRY? Understanding the business, system architecture, and how to deliver fast in the context of what’s already built.

Short functions and DRY are a near universal component of fast delivery, but they are part of the set of practices that mostly enables faster delivery in the increments after the one they are applied in (though I've certainly had single sprints where my delivery time was better because I implemented a reusable abstraction early one that was used repeatedly in that task) so people focussed on fast delivery (as almost all are) who lack more than a myopic perspective tend to overlook them which has a compounding effect.

So, yes, your long lost of things (of which they are a part) matters more together than they do alone, though I'd say that your list is broad platitudes that almost no one forgets are necessary in the abstract, but where concrete details of the last—including fairly context-independent ones like DRY and short functions, as well as more context-dependent ones—frequently do get overlooked, especially when the return is not mainly immediate.

I don't really have a term for this, but I kind of prefer the 'webtender' model of project management. It shows up in volunteer work quite a bit, but sadly not often in software.

Webtender tells you what you can make with the stuff you've already got. It tells you what you can make with just a few more easily acquired ingredients.

A lot of companies seem to get invested in the Realm of the Possible. Somewhere out there, all of the problems we want to solve have been solved, and we want to combine them together to solve all of our problems at once.

It's kind of cruel, if you think about it. You're asking your people to exhibit all of the absolute best qualities of the industry at the same time, and you often see bad managers ride their people into the ground if they don't manage it.

I've had a few rather memorable disagreements with people over the years about who we should fire and who we should keep. I don't care if you're the best programmer out there. I care if, within the tasks that need to get done, that there are enough tasks that I can trust you will do well and a few you can almost do well (growth opportunity) without monopolizing the work I want to assign to others.

I would much rather get rid of the people who are pretty good on the median, but when they fuck up, they aim for the stars. The former group knows their own strengths (or at least can be convinced of them, sometimes). They're a known quantity. No I won't promote them, but when they walk into my office looking like they're frustrated, my first thought isn't, "Oh shit, what did you do now?"

The evidence you supplied suggests that "this kind of people" can tell what's really important from things that are not (either outright fads or not applicable for this particular business), and they have a track record to show for it.

This was a great opportunity for you to re-examine your beliefs in, for example, necessity of QA [1], and learn when and how to save a lot of time by not writing tests yet achieve business goals for stability and continuity. Instead the lesson you took from it was "20 years of experience - the same year repeated 20 times".

[1] It's not too late though, the knowledge is out there

My personal conclusion is that (unfortunately for people who care about quality and craftsmanship) in many industries it's enough for software to be "good enough". The rest can be covered with sales & marketing.

However I think you misrepresent my comment. I offered a comment pertaining especially to the idea of discrete levels of seniority and that of a single dimension of seniority. My examples with QA, Java 6 etc. were illustrations, not the main point.

>>>>their choice of technology and methodology parochial and antiquated (think Java 5-6, Ibatis in 2016 + a lot of in-house built stuff...

Never look at what those guys in the banking industries are still using, you'll have a heart attack. I hear it is something ancient like Fortran and such!

>>no code reviews, no QA etc.

I find it hard to believe that something like this wouldn't collapse under its own weight fairly quickly.

> I find it hard to believe that something like this wouldn't collapse under its own weight fairly quickly.

At least in the case of that company the collapse will be a slow crumbling, not a big bang. What I expect will happen is that 5-10 yrs from now they will be out competed by nimbler new-comers. By then however all the important people will have executed their options, gotten their bonuses etc. and moved on. The rank and file will remain unhappy, there will be churn and nothing will change.

No one is perfect. No one can check all the boxes. Having the desire to try to check them all is the key. Quoting the last part of the article here.

To me, whoever checks most of the boxes defined in this article and has a good mindset would make the cut.

Reply on news.ycombinator.com