Ask HN: Are my expectations on code quality and professionalism too high? • Hacker News Board

Re: Ask HN: Are my expectations on code quality and professionalism too high?

#281

Post by ahefner » Fri, Jun 05, 2020, 10:21 PM UTC

tarsinge wrote: post #277

JamesBarney wrote: post #245

Earlier quoted context omitted.

I really wish we had more precise terms for tech debt. For instance I think type/schema debt (where your domain model has changed from your original type/schema debt) is very painful and has a very high interest rate. I think duplicate domain logic has a medium to high interest rate. I think code organization(what methods go where) has a low to medium interest rate. I think white spacing, duplicate non-domain logic a…

My take is that the highest tech debt is never duplication but always abstraction. Duplication make the job tedious and error-prone, but a wrong abstraction in the start and suddenly you have an insurmontable rewrite of everything for the unexpected change or feature that comes in and wasn't envisioned in the beginning. And it'll come, until you have product market fit and are not a startup anymore.

Agree, and in theory duplication is easy to refactor and clean up, but the nasty thing about duplication is that the instances can diverge in little ways, and then the person cleaning it up may not be able to tell if the differences are meaningful and need to be preserved, or accidents of maintenance.

Re: Ask HN: Are my expectations on code quality and professionalism too high?

#282

Post by tracker1 » Fri, Jun 05, 2020, 10:42 PM UTC

tarsinge wrote: post #277

JamesBarney wrote: post #245

Earlier quoted context omitted.

I really wish we had more precise terms for tech debt. For instance I think type/schema debt (where your domain model has changed from your original type/schema debt) is very painful and has a very high interest rate. I think duplicate domain logic has a medium to high interest rate. I think code organization(what methods go where) has a low to medium interest rate. I think white spacing, duplicate non-domain logic a…

My take is that the highest tech debt is never duplication but always abstraction. Duplication make the job tedious and error-prone, but a wrong abstraction in the start and suddenly you have an insurmontable rewrite of everything for the unexpected change or feature that comes in and wasn't envisioned in the beginning. And it'll come, until you have product market fit and are not a startup anymore.

Was going to say the same... I've been in projects where the abstractions made what should be a trivial 30-60min change, with tests, blows up to almost a week just because all of the layers that need to be worked through.

To GP: schema debt is usually from adding stuff before you need it... it's almost always pre-mature and one should have a good migration strategy in place early on in order to support destructive (or at least not-simple) restructuring over time.

Re: Ask HN: Are my expectations on code quality and professionalism too high?

#283

Post by tracker1 » Fri, Jun 05, 2020, 10:50 PM UTC

PragmaticPulp wrote: post #169

eitally wrote: post #162

Earlier quoted context omitted.

When I was managing a large, distributed team of mostly mediocre engineers (at a poor bigco), it was common to take the best case estimate (provided by a senior engineer or architect), add 50-100% because due to lack of similarly experienced engineers responsible for day-to-day coding, add 25-30% for SQA, and add 50% for "business" delays (usually LOB heads who couldn't agree on features, or who asked for utterly stu…

It sounds like you had distributed decision making authority but concentrated accountability for the outcome. Worst-case scenario. > the senior engineers knew our estimates were crazy high compared to what they'd be able to do independently Interestingly, I worked at a company where teams of engineers were given wide latitude to design, implement, and deliver their features in isolation. The theory was that engineers…

I find my sense of laziness keeps me from going too far down a rabbit hole most of the time.

Re: Ask HN: Are my expectations on code quality and professionalism too high?

#284

Post by quantified » Sat, Jun 06, 2020, 1:03 AM UTC

Is this a startup/young company or a more established one? “Enterprise”, “consumer”, “b2c”? Some comment threads are related to a “publish or perish” situation at under-resourced startups. If this is “b2b” enterprise, I’d despair and look for greener pastures.

I am working now with a code base that was created during a time of such a mentality, but it wasn’t true, just fashionable 8 years ago. So much of it sucks, no functioning architect to ensure basic design quality or consistency. Thankfully, for the first time in my career, I have management committed to getting the worst bits in order, they seem to understand how costly all those earlier “savings” were. Thing is, it wouldn’t have cost more to do it right the first time. Engineers just would have needed to design correctly and implement correctly. Which may have cost more eng $$ in the beginning, but we’d also have had $MM more in referenceable customers as a result.

FWIW I have the responsibility of raising the quality via design review and code review, as well as designing and coding. I’m one of those architects now. Seems to be working.

Re: Ask HN: Are my expectations on code quality and professionalism too high?

#285

Post by Silhouette » Sat, Jun 06, 2020, 1:03 AM UTC

planxty wrote: post #67

Silhouette wrote: post #17

Earlier quoted context omitted.

There are also many companies that go overboard with their code review and tests, get none of the intended gains, produce more slowly than they can, because of an attempt to cater to the lowest denominator. But I suppose if you're going to pick one of two extremes, that would still tend to be the lesser of two evils. I'm not sure that's necessarily the case. IME, not much will kill both the pace of development and te…

Testing is a skill to learn like anything else. Teams that dogmatically apply any new practice or process without making a genuine effort to learn that thing will never extract value from it. If your team can try, fail, and learn from mistakes, you are in a mature organization. If your team gives up quickly because of fear of dogma or has no strategy for dealing with the challenges of learning new skills, it's unlike…

IME, the problem more usually happens because someone in management read a book and thought "I know, we can change our entire development process to do this thing I just heard of and overnight my team will all become 10x developers!"

If you've got a team that is genuinely interested in improving and willing to work on new ideas to make the best use of them, both reviews and testing can obviously be very helpful. That's not really the situation I'm talking about above, though.

Re: Ask HN: Are my expectations on code quality and professionalism too high?

#286

Post by morty_s » Sat, Jun 06, 2020, 2:40 AM UTC

I’ve found myself thinking similar thoughts (as OP) at a startup I joined. It seemed like no one valued code quality, yada yada.

If the things you value are valuable in your new environment, you’ll find the tact, time, and patience to improve the codebase.

One thing that helped me was helping others. Writing documentation, documenting processes, playing dumb sometimes...

Your standards are _not_ unreasonable, but they are _your standards_. If you want others to adopt them, you must lower the cost for them to do so—and must do so in a genuine way.

Lately, I’ve found the quickest way to be “right” is to allow others to be “wrong.”

Re: Ask HN: Are my expectations on code quality and professionalism too high?

#287

Post by raihansaputra » Sat, Jun 06, 2020, 3:19 AM UTC

jrs235 wrote: post #213

raihansaputra wrote: post #128

Earlier quoted context omitted.

Really, really agree. Especially on the last point. Having a small, experienced team is I think the least risky way to build products. Taking the right shortcuts is the big advantage here. Not only about technical debts, but also on reducing planning things to the last detail and reducing overhead on researching best practices for a non-proven stack.

Can you clarify your last sentence? Do you mean not spending too much time planning things out to too much detail?

cies is correct but I'd like to expand the point. A junior engineer (like me) might have encountered tens of systems, and work in less than ten. Senior/more experienced engineers encounter and work in much more. They know which things to implement. For example, let's implement an authentication system for a SaaS. The junior engineer will ask for specs to the brim to avoid missing anything. How to do forget password? Password requirements? Social logins? While the experienced can see the contexts, pick the suitable decision and implement it quickly. They will be more concerned whether the auth will need to support OAuth to smooth out onboarding or to put it off later because their target demographic is more familiar with email/password. These kinds of shortcuts compound to reduce anxiety, increase velocity, and to iterate faster when the product hits the market.

Re: Ask HN: Are my expectations on code quality and professionalism too high?

#288

Post by megameter » Sat, Jun 06, 2020, 3:30 AM UTC

tarsinge wrote: post #277

JamesBarney wrote: post #245

Earlier quoted context omitted.

I really wish we had more precise terms for tech debt. For instance I think type/schema debt (where your domain model has changed from your original type/schema debt) is very painful and has a very high interest rate. I think duplicate domain logic has a medium to high interest rate. I think code organization(what methods go where) has a low to medium interest rate. I think white spacing, duplicate non-domain logic a…

My take is that the highest tech debt is never duplication but always abstraction. Duplication make the job tedious and error-prone, but a wrong abstraction in the start and suddenly you have an insurmontable rewrite of everything for the unexpected change or feature that comes in and wasn't envisioned in the beginning. And it'll come, until you have product market fit and are not a startup anymore.

The difficulty in our current culture with abstraction mostly derives from taking "don't repeat yourself" too far and using that to mean "apply any compression strategy you can find to this code" which could range from enterprise generalization and configuration to APL-style code-golfing.

A gentler, more helpful admonition would be "find the theme, reuse the theme". If you only set out to compress the code you obscure the theme of the code, but if you set out to elevate the theme as you find it, you are likely to let more code rest in a form that is duplicated but a reasonable reflection of the themes currently present.

Re: Ask HN: Are my expectations on code quality and professionalism too high?

#289

Post by julius_set » Sat, Jun 06, 2020, 8:32 AM UTC

aerophilic wrote: post #123

ransom1538 wrote: post #56

Me as a manager at a startup: "Look, we have 5 months of runway. Does that make sense?" Young dev from large corp: "Yes. But if you don't use Terraform we wont be able to see our infrastructure changes over time. We don't even have a proper code review process." Me as a manager at a startup: "We have two micro instances. Do not install Terraform. Finish the import prototype... now." Young dev from large corp: "Sigh,…

This. Though, I think the exact example may be debatable. The (appropriate) question was “We have 5 months of runway, does this make sense?” Assuming the manager is halfway competent in listening to their team, then this should be a useful focusing activity for both the dev and the manager. In business, and in life, it isn’t about what you “can” do, it is more about focusing on the handful of things that give you the…

You’re assuming the manager hired senior engineers who can competently know the best strategies in each. By contrast an inexperienced engineer might take the worst path

Re: Ask HN: Are my expectations on code quality and professionalism too high?

#290

Post by mbrodersen » Sat, Jun 06, 2020, 8:58 AM UTC

Making short-term-good-long-term-bad decision might be the right thing to do for a small company in order to survive long term. However nothing stops you from doing the best you can given the circumstances.