I am not convinced that you are competent enough to be an engineering manager at a big company with oversight from an experienced manager, nevermind at a startup. You've revealed a cascading set of failures here that are 100% your responsibility and then have the audacity to caricaturize your well intentioned junior engineer:
1) Having 5 months of runway is an existential problem that your CEO's fundraising should have addressed 7-12 months ago
2) Lacking a proper code review process ensures that you'll pay pounds of prevention long term instead of ounces of prevention, which over the long term is not a frugal usage of your already scarce engineering resources
3) Your senior engineers should be having the conversation with your junior engineers about the tradeoffs of heavier vs lighter forms of code review and CI process. Unless...
4) You hired a junior engineer as your early or first employee without a senior engineer and are unwilling to do the necessary work mentoring them yourself
You are responsible for each of these failure modes. Who made the decisions to get the company to a place where it only has 5 months left of cash? Who made the decision as a startup manager to let other managers take it there? Who made the choice to hire the junior engineer? Who made the decision to forgo proper code review standards?
It sounds like your junior engineer has a sense that they are on a sinking ship. Maybe they're right. You're one of the captains. Turn it around, or cut your losses and learn from your mistakes. Saying this as someone who has been a startup manager, I think it is a profound breach of the duty of leadership to not do so, which is what it sounds like you are doing right now.
EDIT: In case you need some pointers or some food for thought, I think that another HN thread that's also on the front page could be a great place to start:
Remember that management is not the same as IC work at a higher seniority. It is a fundamentally different vocation. You really need to internalize that to be effective and it is tricky.
I am not convinced that you have ever worked at the average startup. Your points are incredibly divorced from the reality most face.
Years worth of runway is not the norm. Having your choice of senior engineers to hire right away is not the norm. Most startups exist as sinking ships.
It sounds like you lucked in to a company that raised a shitload early on and so had the luxury to make these decisions.
> Your points are incredibly divorced from the reality most face.
> It sounds like you lucked in to a company that raised a shitload early on and so had the luxury to make these decisions.
I worked for a string of them early on in my career. I was miserable and worried that I'd never get anywhere better because of the scarlet letter of working at a failed company (and several of them) would be my first impression. Rather than blaming it on luck, I resolved to figure out where I went wrong and how I could avoid it in the future.
While you cannot remove the element of timing and large scale market events outside of your control, startups are about making (and learning to make) calculated risks. Mediocre startup operators love this kind of argument (so and so can do things because they raised more money than us because they're lucky not because they executed better) because it lets them escape the consequences of their own unforced errors and ineffective execution. You won't hear this argument from effective operators because it would get laughed out of the room. They know that they have to operate proactively, not reactively from (and even before) their first fundraising event.
The most well run companies have a tendency to create exponentially more, not less, expansion and subsequent job opportunities. My advice is don't work for a risky early stage company until you learn what success looks like somewhere bigger. At an early stage startup that's on the right track, you'll see a lot of the same things just in a smaller org. But it's hard to know what you should require unless you've at least seen what it looks like to work at a well oiled machine. Folks that tell you otherwise are either ignorant or willfully trying to pull the wool over your eyes.
Counterpoint: Twitter's codebase early on was a well known clusterf%%% that was impossible to scale reliably and was consistently causing the fail whale. They found product market fit, got funding and improve their code.
Counterpoint #2: Amazon's code base was a monolith and highly dependent on Oracle. The rest is history.
The order of priority is to have a product that customers want, convince investors to give you more money to continue your growth and improve your infrastructure and hopefully become profitable or at least have an exit strategy.
Git didn't exist, SVN didn't exist before 2000. Common languages in use today didn't exist or were in their first versions (go, python, java, etc...). Most of the unit testing frameworks and IDE that are taken from granted weren't invented yet.
There were different expectations back then. No software company should be running in 2020 with no version control, no unit test and no CI.
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 having the later tools/frameworks/infrastructure at disposal.
Funfact: The java compiler was still fixing "bugs" in 2016 to be able to produce an identical JAR between builds.
Nowadays if an intern opens PyCharm. He can get right away a lint report on the current file and entire codebase, finding potential bugs and questioning why is this thing not running automatically on commit. This pushes quality up organically quite a bit. By comparison doing embedded C++ development in the 2000's, I can only recall of one company having a static code analyzer, that costed no less than $50k for a handful of small projects (they charged by line).
I can't really blame them for nondeterministic builds. Not only was Java slower but computers in general were slower when javac was written, so recompiling unchanged source files was an obvious waste that everyone tried to avoid (by checking mtimes, because hashing every file was also pretty expensive).
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.
I think this is generally a great comment, but just to note: you seem to characterize the "5 months of cash" thing as a decision. But most startups fail, and all of those startups at some point (or multiple points) in time only had 5 months of runway left, which is not always (I would say not usually) because they decided it was ok to have that little runway, but because they could not avoid it despite their best efforts.
But you're totally right that this is not the junior dev's problem!
> they could not avoid it despite their best efforts
I think we're making the same point, but I don't disagree. I think this is what I'm getting at. A CEO who cannot raise and is at 5 months of cash left has a) effectively gotten a vote of no confidence from their existing investor base, or b) they are not asking because then they are delaying the inevitable and eventually impossible to ignore conclusion a). Not being able to avoid low cashflow despite your best efforts is a failing on the CEO's role. The CEO is the last line of defense in terms of responsibility, and fundraising is supposed to be one of their core competencies and responsibilities. It's why the job is not for everyone.
1) Having 5 months of runway is an existential problem that your CEO's fundraising should have addressed 7-12 months ago
2) Lacking a proper code review process ensures that you'll pay pounds of prevention long term instead of ounces of prevention, which over the long term is not a frugal usage of your already scarce engineering resources
3) Your senior engineers should be having the conversation with your junior engineers about the tradeoffs of heavier vs lighter forms of code review and CI process. Unless...
4) You hired a junior engineer as your early or first employee without a senior engineer and are unwilling to do the necessary work mentoring them yourself
You are responsible for each of these failure modes. Who made the decisions to get the company to a place where it only has 5 months left of cash? Who made the decision as a startup manager to let other managers take it there? Who made the choice to hire the junior engineer? Who made the decision to forgo proper code review standards?
It sounds like your junior engineer has a sense that they are on a sinking ship. Maybe they're right. You're one of the captains. Turn it around, or cut your losses and learn from your mistakes. Saying this as someone who has been a startup manager, I think it is a profound breach of the duty of leadership to not do so, which is what it sounds like you are doing right now.
EDIT: In case you need some pointers or some food for thought, I think that another HN thread that's also on the front page could be a great place to start:
Remember that management is not the same as IC work at a higher seniority. It is a fundamentally different vocation. You really need to internalize that to be effective and it is tricky.
https://news.ycombinator.com/item?id=23427110
https://news.ycombinator.com/item?id=23429785