Earlier quoted context omitted.
I think you have some things to learn, as a manager, and as an engineer.
Don't we all? What exactly do you mean? Two micro instances don't seem to warrant using Terraform
They probably warrant CI and tests though.
Ask HN: Are my expectations on code quality and professionalism too high?
101–110 of 306 posts
Re: Ask HN: Are my expectations on code quality and professionalism too high?
#102I've worked for both types of companies. It's surprising that both cultures work in their own context.
At the startup I worked where the dev process was zero, we were able to flesh out pivots and products at a pace that was able to bring continuous investments to the company. To be honest I didn't enjoy the craft though during that time. There was no depth, but a lot of breadth. It was just about churning out code like a machine.
At the bigger company where I work now, money stopped being a factor. I was able to afford time to ask fundamental questions about my code. My code was reviewed and shipping was governed by a process that scrutinized devs. Slow and sometimes frustating, but still enjoyable given the freedom of time I was now given.
At any day, I'd pick working for a large-ish company than a early stage startup unless it's a startup that makes things I care about.
Re: Ask HN: Are my expectations on code quality and professionalism too high?
#103Another issue is agreeing on that bare minimum. I'm okay with shortcuts, but I need a clean git history as my mainstay to understand how the mess happens. Other's think that managing branches is a waste of time :(
Re: Ask HN: Are my expectations on code quality and professionalism too high?
#104Me 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,…
Folks are focusing on "five months of runway" or other minor details and missing the big picture here.
Big companies typically have fewer constraints on time, money, and developers. They can have very mature development processes because of that.
Small companies typically have tighter constraints. It's not as if this hypothetical manager doesn't want better process, but if the things to spend time on are "better deployment methods" or "ship this feature in time to land a critical contract," there's no choice there.
OP has, potentially, a unique position here. If they can find a way to use their experience to help implement small process changes without grinding development to a halt, they can seriously improve their team and maybe emerge as a leader as well.
This is different from "we need to stop and do all-team code reviews before every PR merge!" The time may not be there, and the management buy-in sure isn't.
But encouraging teammates to add new tests with each new feature, and helping folks who may not know how to do that, can have a huge impact. Taking an hour or so Friday afternoon to gather the team and casually review merged PRs or do a sprint post meeting over drinks can be a good unwinding activity.
OP's got an opportunity here.
Re: Ask HN: Are my expectations on code quality and professionalism too high?
#105Near the start of my career I was at a small/medium sized company on a tiny engineering team (3.5 people). We also had a lot of responsibility. Naturally we did the only thing we could and formed silos and worked in our individual silos without too much regard for testing or pull requests. We had a lot of communication and I personally owned the "back-end" and was able to ship stuff fast. I knew how every piece of code worked.
We eventually (to our protest) got a few new developers. They didn't fit in our silo system. Our lack of tests/PRs didn't scale. We tried to reform and encourage people to use pull requests but everyone requested review from one developer who hardly looked at the code (scroll-scroll-scroll-lgtm reviewing.) Code added from people outside of a silo didn't fit in at all with the rest of the code base. Testing was never made a priority. Eventually I left and took with me almost all of the institutional knowledge about some of our services.
We made horrible practices work until they didn't. No one would have been able to join that team and fix it. The company I left for had mandatory testing, multiple people code review and lots of discussion. It was like stepping in to an entirely new world of software engineering. In my view you need to install a good culture from the beginning or... good luck.
Its all about what you value as an engineer. You and I have similar values in this regard and good practices are worth a lot to me. I don't think your ask is unreasonable at all. I think you are just working with people with different values.
Re: Ask HN: Are my expectations on code quality and professionalism too high?
#106[deleted]
Re: Ask HN: Are my expectations on code quality and professionalism too high?
#107Counter these examples with small companies paralyzed by process, introduced by well-meaning hires from large companies with plenty of capacity.
A large company is a marathon run. Discipline, strategy, training matter.
A small company is running from a bear with your hair on fire.
Re: Ask HN: Are my expectations on code quality and professionalism too high?
#108I have no advice because you never mention anything about the customer. Reframe the argument if you want to be persuasive with the powers that exist.
Re: Ask HN: Are my expectations on code quality and professionalism too high?
#109It depends on the cost to the end user and the cost of failure. At one end of the spectrum you have free-to-play games. You'd have to be insane to implement a high test coverage on that. Nobody cares if Battletoads Royale crashes. On the other end of the spectrum you have safety critical software, financial software, etc, where the costs of failure are very high. Ask yourself "what's the worst that can happen if this…
Yep. I'm reading a book right now called "Click Here to Kill Everybody [1] and it discusses exactly this. It also considers the financial cost involved. What is the cost of establishing and maintaining a CI/CD system that OP is proposing? And what is the cost of a bug / deployment error? In the last decade (assuming the company has been around that long), how often has a deployment error occurred? How much time saved will occur due to automating deployments?
Unless the errors are substantial, or the time savings for staff are significant, it's unlikely that organizations will invest significantly in non-business / non-consumer facing technology. Unless software is their business, then having mature CI/CD systems helps the company attract strong candidates, like OP.
Re: Ask HN: Are my expectations on code quality and professionalism too high?
#110Me 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 is why it's important that early team members are experienced engineers. They know which corners should be cut today to get the prototype out, and which shouldn't because they'll take 30 mins to do "properly" and save a day of work before the runway is even up. I work in a small company that has all the things the author mentioned and that can work quickly as a result. Almost none of it comes from "we'll do it t…
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 deliver quicker, and it's incumbent on management to facilitate remedying that tech debt at the earliest available convenience. If management does not facilitate removing tech debt by allowing for such refactoring/structural work it is then incumbent on engineering to stop offering the shortcuts that temporarily increase velocity, because there's already too much tech debt to be had, and to take on more will reduce velocity unacceptably.
A good startup has experienced engineers and experienced managers who understand this dynamic.