Live data from Hacker News

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

news.ycombinator.com

271–280 of 306 posts

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

#271

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,…

> Young dev from large corp: "Sigh, ok, just saying in 2 years from now we wont be in a good spot". Except in my experience it’s not two years , it’s two months . And I can set up two micro instances with terraform in less than an hour. So soon you’re burning your three months of runway with development at 20-50% efficiency, and have no ability to pivot, if needed, because your infrastructure is rigid and hardcoded.…

If you can set something up in an hour, don't discuss it; show it. Spend the hour, show it works. If it does, fantastic. If it doesn't, drop it.

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

#272

Earlier quoted context omitted.

Skipping tooling & processes below a certain (not very low) point isn't doing it "cheap and fast". It's saying "I want you to build my house but I want it to be cheap so don't buy any more hammers, it's too much money and we can't afford the time for you to run to the hardware store, just all share the one hammer you already have". It's doing it cheap (but actually expensive) and slow and low-quality.

You really want to build that house and I respect that, but the client just wants a tent and the hammer budget is zero. And since a storm is 10 minutes away they're not wrong...

And you can build a tent quick, cheap and fast. Getting customers to tell you want they really need is the silver bullet.

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

#273

Earlier quoted context omitted.

Source control very much did exist in 1995. Twitter was initially built on top of Ruby. Java was very big in the Enterprise by 2005 and yes there were plenty of IDEs back in 1995. Amazon I believe was originally built on a C code base. There are plenty of companies that have no automated unit tests and do quite well with manual testing. But we aren’t just talking about source control and unit testing we are talking a…

Double checking the dates. CVS is 1990 (source control before SVN before git). Visual Studio first release is 1997. Eclipse and IntelliJ are both 2001 one month apart. PyCharm is 2010. Jenkins CI is 2005 (initially named Hudson). Teamcity is 2006. Code quality is limited to the tools available at the time. It was an uphill battle to preach for (automated) scripted builds or any form of (automated) testing without hav…

I doubt very seriously that Amazon was running on Windows servers so I fail to see the relevance of Visual Studio. Even so, the first version of Visual C was released in 1993 (https://winworldpc.com/product/visual-c/1x).

C is not a new language. People have been writing large well structured C code for decades. The first C linter was written in 1978. Even PC-Lint was written for C in 1985.

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

#274

No, i would say that your standards are quite reasonable. I would also say that there are many companies that do not meet those standards. Usually they have no excuse for doing so, just that no one there knows or most likely just don't care. 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 cate…

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…

I think if we're considering the morale of the engineers, then they would prefer to work in a wild environment rather than an overly rigid one. In a sense, it's fun to write bad code, commit it without consequences, and just watch a report of your LOC go up (the key metric for engineers in this strawman company).

I think from the business perspective, they would rather have slow to no changes rather than breaking changes. Presumably there is already a product that makes money, and would continue to do so if kept in a maintenance mode. Layer on poorly applied practices, and you've effectively turned it into that.

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

#275

Earlier quoted context omitted.

It's not the coders, it's the management. And sometimes it's not the management, it's the business, which is the market, which is the customer.

Do you have customers who want fast but unstable products? I don't. On the contrary, when we talk to them about our product roadmap, they are more than happy to wait for new features in order for us to improve the stability.

What if your customer is the government and your users have no choice in the matter?

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

#276

Earlier quoted context omitted.

Do you have customers who want fast but unstable products? I don't. On the contrary, when we talk to them about our product roadmap, they are more than happy to wait for new features in order for us to improve the stability.

What if your customer is the government and your users have no choice in the matter?

My customers are 100% government entities, so I'm not sure what you mean?

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

#277

Earlier quoted context omitted.

I highly agree here. Do not staff a very new startup with junior engineers and expect a good outcome. Furthermore, you absolutely do need to cut corners _somewhere_, but a seasoned team understands that taking on such tech debt will require a reduction in velocity at some point in the near future. It is then incumbent upon engineers to ensure management understands that the team is borrowing from future velocity to d…

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.

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

#278
Your $current_company needs the reality check.

I run a 4 person dev team at my tiny 8 person startup. We kinda do all the things you mention. CI, reviews, auto deployment. Our test coverage could be better but is increasing by the day.

What you expect is totally normal.

I bet the current co has weak technical leadership

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

#279
I depends from what you derive your satisfaction. I've been at a company that had perfect engineering practice and was completely failing because engineers were almighty and oblivious of business. That was demoralizing. A useful product makes me more happy. Code quality is not an absolute end goal. Sure I would prefer to have both, but in reality it's usually a tradeoff, and over-engineering is worse than under-engineering when in doubt. Also I've seen shitty over-engineered (edit: from a user experience perspective) monstrosity with very good "code quality", and hand-crafted delightful to use apps that would not check much on your list.
Post reply on HN