13 ms·

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 won

• brayhite 6y ago
  Your scenario can be a lose-lose situation as it applies to the question. Speaking from experience, you can do the “agile” approach do fail fast, release faster, but with no buy-in from leadership to address the breaks in the future, your compounding problems on problems. So, short-term, you have happy leaders who see releases as they want, and unhappy devs who are in a shitshow of code. Long-term, if your startup is either acquired or starts to grow a strong revenue stream, leaders need to appease their new owners or their influx of new customers, and you can’t slow down because either a.) the new board needs to be impressed to justify their large acqui-investment, or b.) your new customer base is too big to risk losing. So you keep building on bad code, maybe squeezing in a few skunkwork refactored that only the dev peer reviewing and QA know about, and accept any delay on release as the result. The approach should be somewhere in between, ideally with the engineering team being empowered to tell leadership “yo, we have a bomb of bugs just waiting to burst if we add one more feature with duct tape, let’s prioritize time to address it”. If leadership doesn’t trust your team, then you have bad leadership.
  • darkerside 6y ago
    Is there any situation under which leadership shouldn't buy in to exactly what tech wants to do?
    • pletsch 6y ago
      Does a captain of a ship do exactly what his crew wants all the time? No, because they're steering a ship and sometimes they have to make moves that not everyone will agree with.
      • mondoshawan 6y ago
        Erm... That's not how sailing works. Yes, the Captain needs buy-in all the time, since they are ultimately responsible for the ship and crew both in the eyes of the law and survival wise. Also, most of the time the crew is at the helm. Source: I'm a trained sailor.
    • chasd00 6y ago
      Scotty wasn't on the bridge, he didn't know what was out the window.
      • karatestomp 6y ago
        Point of order: Scotty was frequently on the bridge commanding the ship, and there's a strong argument to be made that he was the second-best at the job, after Kirk. Certainly 3rd best.
        • chasd00 6y ago
          i voted you up, it was a risky analogy given my limited knowledge of Star Trek compared to the majority here :)
    • adrianN 6y ago
      Hopefully there are situations where the leadership has more information available than the engineers.
    • darkerside 6y ago
      This is a little embarrassing. I asked what I thought was a well-designed question to frame the problem in a way that made my own conclusion obvious. Clearly, I missed the mark, so I'll be more straightforward now. Engineers below the upper senior levels typically operate with an "infinite" mindset in making these choices. We all laugh at the relevant XKCD[0] because there's a grain of truth in there. This isn't a knock on engineering, it's just the nature of operating at the lowest levels. You become involved in the problem and you solve for local maxima. Leadership done well is going to offering transparency to the people on the ground level, communicating timelines and strategy in a way that is relevant to the problem at hand, so people know, for example, how long they can spend solving a particular problem. Where this sometimes goes wrong is, the higher you go in leadership, the lesser certainty there is. There are no "right" answers, there isn't perfect information, and yet, decisions must be made. If engineering is operating on different base assumptions, those decisions will look wrong (and they might be). And yet, someone needs to get people aligned and moving forward, because moving fast in the wrong direction is typically better than moving too slow, even in the right direction. [0] https://xkcd.com/974/ https://xkcd.com/974/
      • SAI_Peregrinus 6y ago
        Or this one, which provides good info on whether to take the time to automate something: https://xkcd.com/1205/ https://xkcd.com/1205/
  • rezonant 6y ago
    So much this. There is such a thing as YAGNI in the early and tight days of a startup but tech debt is something that needs to be constantly addressed, and you as a manager need to trust your team to put in the proper engineering as a solution grows. Is quick and dirty fine for a prototype or MVP? In theory yes, but understand that a lot of devs have seen that turn into the final product (with customers on it within days of the "prototype" being finished in some cases). I've seen it with some of the worst codebases I've ever encountered, and those "prototypes" and "MVPs" were never overhauled with a scalable architecture, and the startups end up running out of steam because they did not invest in their product codebase, or better, have a sustainable pace of development that allows the solution to constantly remain high quality. Don't have the runway for that? Are you managing the startup as well as you could? Why did you tell your investors that you could do it in five months of dev time?
• BerislavLopac 6y ago
  > Then proceeds to blow 2 hours complaining on hacker news You are absolutely right, that was wrong. They should have instead ignored you and install Terraform.
  • rezonant 6y ago
    Why not both?!
    • jerkstate 6y ago
      <next week> where's the import prototype? check it out, I moved our metrics stack to InfluxDB and Grafana! Now we can scale to 10,000 instances no problem!
• p0nce 6y ago
  How long has your startup been in existence? If it's more than a few years and you haven't found market fit then it explain why you have "5 month of runway"
  • deleted 6y ago
    [deleted]
• planxty 6y ago
  I think you have some things to learn, as a manager, and as an engineer.
  • reallydontask 6y ago
    Don't we all? What exactly do you mean? Two micro instances don't seem to warrant using Terraform
    • UK-Al05 6y ago
      They probably warrant CI and tests though.
    • dangus 6y ago
      Once you're experienced writing Infrastructure as Code, you always use it, no matter how small the project is. Right now I run a single micro instance for a personal project and I've got the whole thing Terraformed, which took me less than a workday - VPC, subnet, security groups, S3 buckets, and a basic provisioning script to setup the instance's software and cron jobs. It is (eventually, once you learn it) faster and more intuitive than bothering with the AWS console, and I often reference Terraform's own AWS resource documentation over the AWS docs since it usually has better information density. Anyway, the issue is all beside the point, I think we realize that Terraform was used as a placeholder example. Another example might be setting up single sign on, Active Directory, and other things that are truly not necessary for a company of that scale. The other part of this that if you've got a startup with 5 month runway and 10 employees, hiring an Infrastructure as Code SME is probably not the best use of your dollars. Sure, I was able to put this side project in Terraform in under a day, but I also can't write a front-end application to get myself out of a wet paper bag.
      • hef19898 6y ago
        Not sure about the run-way thing. I'm also partially a six sigma / lean guy, and doing things right in the first place is a key lesson I learned, sometimes the hard way (aerospace definitely drove this home as well). I would make the case that, even with 5 months of runway, you should invest in a solid foundation. Because if the company goes down, it does. Only a little bit earlier. if it doesn't, which is I assume the reasoning behind the company in the first place, getting the basics right now has a huge impact on runway and scalability later on.
• afarrell 6y ago
  When that dev gets older, he'll get the self confidence be honest about his reasons and say, "No. Then we won't be able to see our infrastructure changes right now and in 2 weeks time we will be confused enough that our forward progress will slow significantly."
  • deleted 6y ago
    [deleted]
• viraptor 6y ago
  The time when you have 2 micro instances is the best time to implement terraform. You can do it in 5min, existing infra is obvious, and you likely can explain it to 2 other people and be done. Once you're established, growing, and accumulating features it will take weeks/months. (And if you need a duplicate environment for staging, how many clicks will it take?)
  • jpdb 6y ago
    I thought the same thing, but after reading what the comment said again it wasn't a "use terraform or don't" story, it was terraform vs "import prototype". Generally for most resources, I feel like I can write terraform just as fast as I could create the resources in the console. Probably not a good example, but I agree with the sentiment that you have to prioritize the business.
    • phonebanshee 6y ago
      And it depends on existing skillsets too. I did a recent project where I almost certainly would have used Terraform if I already knew how. But the choice was between "learn Terraform" and "do this in a Makefile," and the "learn Terraform" was clearly crazy overhead at the time.
• myvoiceismypass 6y ago
  Rapid prototyping does not mean abandoning established programming practices that help people feel confident about their work.
  • onion2k 6y ago
    Yes it does. The clue is in the name - prototyping. A prototype is only supposed to prove the concept works; it doesn't need to be good. The problem is that most companies can't do prototyping because they don't have the resources. They build a prototype, and then they don't throw it away and build the proper version and they use as production.
    • brain5ide 6y ago
      I was hoping to see the word 'protoduction' in your comment.
      • jbn 6y ago
        This is such a good word, great find! There are so many things in production that are prototypes (even when people/companies cannot allow themselves to recognize them as such...), having a word for this pattern is great.
  • crad 6y ago
    In my org, I have created a process to clearly define what makes a prototype different from a MVP. It appears to be somewhat successful for what my goals were, which was to prevent prototypes from turning into long-term production code. Prototypes have no restrictions that we would normally place on code (coverage %, automated pipelines, etc) and can only be created in a sandbox AWS account that has no access to our internal systems. It allows developers to prove out concepts or work with product to quickly iterate on PoC. On the other side, PoC's have a limited lifespan and if successful, are expected to be re-implemented as an MVP, following our internal standards and guidelines.
    • ncallaway 6y ago
• nonines 6y ago
  The point I think you're making is that "it depends" and I agree with it. I've seen companies that have no funding issues building products that they know they will need to maintain in coming years and still follow a few or none of the best practices. But I've also seen people building SW that no one can guarantee that will ever be used (and gets scrapped after a few months) spending days and weeks setting up the perfect agile CICD setup and arguing in endless pedantic discussions in code reviews.
  • rezonant 6y ago
    All things with balance, and I agree analysis paralysis and overengineering are real problems to avoid... but I'm sorry you can't deploy without CI/CD unless it's like a desktop or mobile app or something. You don't skip that for servers. Does it have to be perfect? Hell no, but it needs to be in place before you can seriously call it shipping
    • gowld 6y ago
      Plenty of Unicorn IPOs disprove this thesis.
    • phonebanshee 6y ago
      I'm guessing that you work on server-side stuff, because most people who do mobile/desktop work would say exactly the opposite if they desperately had to come up with a general rule: do whatever you want for servers, but you have to do things right for mobile/desktop. Those are your servers, and you can fix them whenever you want. You push software to end users, and it's gone forever.
      • rezonant 6y ago
        I do, mostly. Also anticipated there'd be at least one mobile/desktop app dev who would swoop in to say it's important there too and I agree! It's just so common to have two servers to deploy to, and as soon as you do, you aren't going to repeat manual steps to deploy your software on them. I guess in that sense app stores are sort of like CI for apps :-P But indeed, especially on mobile where you need to have releases go through external validation, CI/CD can save you a lot of time.
• danpalmer 6y ago
  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 this way", almost all has evolved over time as we've been able to gradually introduce more rigour to our development process. Much is down to some great engineers at the beginning setting us on that path.
  • rezonant 6y ago
    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.
    • raihansaputra 6y ago
      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.
      • jrs235 6y ago
        Can you clarify your last sentence? Do you mean not spending too much time planning things out to too much detail?
• hannofcart 6y ago
  This story is so eerily close to what happened at my company, even as regarding specifics that I was tempted to ask if you are a colleague. :)
• generalk 6y ago
  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.
  • qqqwerty 6y ago
    Exactly this. In a similar situation I am aware of, a senior dev came in, found some measurable bottlenecks, convinced non-technical management that they could be fixed, and then fixed them. He is now the CTO. They key here is to find problems with the current environment that can be tracked. Downtime, performance, bugs in prod, etc... If you can't find any measurable issues that management can relate to, then quite frankly, there isn't really any reason for management to invest in solutions to problems that don't exist.
• Random_ernest 6y ago
  For some years I was the developer you talk about, who always knew everything better, now I am a manager at a startup. So I was able to see both sides of the discussion. I feel like it always comes down to a communication issue. Team members need to feel heard, and feel acknowledged that you fully understood what they are suggesting. On the other hand they need to understand that there are constraints that force a decision that might not technically be the best, but is pareto optimal. When this discussion occurs I sometimes bring up the analogy of these space movies where they put everything on a table that the astronauts have up there and try to make something out of it that mostly consists of duct-tape. Sure there are better tools, but the stuff on the table is all we have. Another thing that took me very long to understand as a developer is that innovation is a risk that might not always make sense economically. A thing that took me long to understand as a manager is that the happiness of your devs is one of your most precious resources that you have to manage well.
  • rrradical 6y ago
    A coworker introduced me to the concept of a 'novelty budget', and I find it really useful. If my team is taking on a new project, there are many ways to improve on how things have been done in the past. But doing anything new carries some risk. If every part of the project is new, it will be very risky. So I use the idea of a novelty budget to negotiate with my engineers. "What things do you really want to change? Let's focus on that, and use tried and true, albeit suboptimal, methods for the other stuff, to stay within our novelty budget." Down the road, once you can handle more risk, you can introduce one of those changes that were originally punted.
    • ChrisMarshallNY 6y ago
      I like that! "Novelty Budget"
• aerophilic 6y ago
  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 biggest “bang” for the buck. Think Pareto law, and how you can get 80% of a result, for 20% if the effort. So, in the context of the scenario, the developer should be asking themselves: 1. What problem does <insert tool/process> solve now or will solve in next 5 months? 2. How painful is the problem, and what is it’s frequency (High impact, but low probability; moderate impact, but high probability). 3. What is the cost of the new process/tool to the team? (Time, cognitive load, $$$ that could be spent elsewhere). As long as ratio of value to cost is large (10X or more), in the timeframe that matters (in this example 5 months, for most companies time is measured in years), and you can articulate it, selling the idea should be a no brainer. However unless you can truly get that 10X(or more) return, then it might be better to focus your improvement activities elsewhere. All that said, I do think the “Command voice” at the end is a bit of an issue... at least for me. You are “pulling rank”. This is “okay” if you have built up the “rep”/karma/trust to do so, but unless you have, will likely make the dev (long term) run for the hills. It might take a bit more time/coaching to explain something like the above to them, but that is an investment in people that lasts a lifetime, whether or not the startup lasts past 5 months.
  • julius_set 6y ago
    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
• an_d_rew 6y ago
  > 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. Neither scenario is “correct”, there is only “judgement”, and it can be devastatingly incorrect either way. A lot of people with strong or extreme opinions (too little or too much tech debt) are inadvertently being fooled by “personal survivor bias“.
  • partomniscient 6y ago
    At the same time, it also means collectively we don't know what we're doing to get where we're going and are just throwing stuff at a wall to see what sticks. It also made me think of the Apollo 13 movie. The engineering/process people got the thing into space, the adaptable/dynamic solve it with 'gaffer-tape and whatever is laying around' people got the thing home. We still need both approaches for different reasons. “Personal survivor bias“ accidentally chooses a side for you. Experience eventually makes one realise there aren't diametrically opposing sides, just different capabilities needed in different circumstances.
    • p_l 6y ago
      Except the people who did the "tape it together"? Those were the same people who made the long process before. That's why they could just tape it together, they were deep in the knowledge of the system they were fixing and thus could tape a kludge together to get them back.
      • partomniscient 6y ago
        But that's because in those days the people that built the thing have to do production support once it goes live. That doesn't happen so much in larger organisations because they have separate teams divided along "add/build something new" and "keep it going" boundaries without a lot of cross-pollination.
• marcinzm 6y ago
  That seems like very myopic management since a) motivated employees will work harder b) technical debt has a continual productivity hit even in the short term. If spending 20 hours on terraform saves the team 100 hours of debugging over the next 6 months then that may be a net win. Keep in mind that due to context switching and flow even a 10 minute "fix it now" bug will use up 2-4 hours worth of productivity.
• gowld 6y ago
  It's because we hire "software engineers" but we actually want them to be "business hackers", but lie to customers and regulators about the quality and integrity of the product. Then we mock them for trying to do the job they were hired for. The fact that pogrammers bias toward rule following (the computer doesn't react well to people bluffing) is part of the conflict.
• _bxg1 6y ago
  Worth noting that the OP said "mid-sized company", which probably means one that doesn't have a runway measured in months. That makes a big difference.
• ornornor 6y ago
  That's not what OP is talking about though. Not using prod DBs for development is common sense and best practice. Not pushing to prod is common sense and best practice. Same thing about breaking tests, spaghetti code without review. It's not some pie in the sky, engineer-wants-to-tinker-with-shiny-toys like using Terraform or Kubernetes would be if you only have 10 paying users and two microservices.
• zebraflask 6y ago
  This, unfortunately and hilariously, rings quite true. Not to open the test-driven development can of worms, either, which seems to be part of the OP's dispiritment ... but I've yet to see any scenario where TDD was not a massive waste of time.
  • baggachipz 6y ago
    Thank you, it feels like heresy whenever I say that... like it's one of those grim realities you're not allowed to point out. I'm all for automated testing in a sane manner, but TDD is so rigid and over-engineered. "Can't fail your TDD tests..." taps forehead "If there's no code to test"
  • p_l 6y ago
    Depends. Is it the crazy religious TDD where you somehow are supposed to write tests before writing any code, despite the fact that you're making exploratory code? TDD works best when you have figured out what to test for, unfortunately more than once I encountered people who wanted to write tests for exploratory code, in rigid TDD like environment. (sidenote: It's possible to do kind-of TDD with exploratory code in certain environments - essentially, you start writing code from top to bottom and fill in missing bits using debugger all the time)
    • rileymat2 6y ago
      I have only toyed with it on personal projects. But that is kind of a misrepresentation from what a lot of them propose. You typically will not be writing more than a part of a test, just enough to get it to fail, before writing the code. It can work good as a built in driver to exercise the code you are trying to write as you go. It also gives you a chance to test the interfaces to the code you are making as you go for usability, because you are coding to it. There are actually some really interesting videos demonstrating the RED/GREEN/REFACTOR cycle they propose.
      • p_l 6y ago
        That's why I mentioned "crazy religious". I've seen it got that far in real world, which warps TDD to the point where a good technique is thrown away by people disgusted with the pushed purity message. It doesn't help that often, even otherwise good material about TDD, didn't really talk about cases like exploratory coding - working from messing around in a REPL, formalizing the code into TDD skeletons, is pretty powerful method, but isn't (wasn't?) mentioned often when I learnt the most about TDD (granted, that was 2005-2015)
• tjbiddle 6y ago
  If you're only running two micro instances, I'm assuming the rest of your infra is small. Likely would have been a single day project to have everything inside of Terraform.
• p_l 6y ago
  Experience recently went the other way around. "It's just simple project, don't bring out the big guns". Somehow, a simple requirement of "make sure we can backup it all and load it elsewhere, manually, nothing fancy" made it so that I lost 5 days purely due to acceptance of manual work at the start.
  • chousuke 6y ago
    I'm gravitating towards trying to pick automation tools that I can replace easily, but I don't skip automating things. Often, creating things using proper automation tools ends up being significantly faster than doing things manually, and the result is better. If I'm setting up a proof-of-concept, I'll at the very least try to write a shell script that contains whatever it is I did to get a host set up. If doing stuff for production, I might have one instance where I set up things manually while simultaneously writing the appropriate automation to get another instance up and running. That allows me to iterate the set-up quickly while allowing me to verify the result by recreating it from scratch using the automation I made.
• yowlingcat 6y ago
  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. https://news.ycombinator.com/item?id=23427110 https://news.ycombinator.com/item?id=23427110 https://news.ycombinator.com/item?id=23429785 https://news.ycombinator.com/item?id=23429785
  • sanderjd 6y ago
    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!
• blub 6y ago
  If that team can't even do code review and they're pushing to production as OP said, maybe the startup should proactively close shop and everyone should go back to something they're competent at, like growing potatoes.
• sanderjd 6y ago
  Newly hired experienced eng lead a year after this conversation: "Ok we won the product-market fit lottery with our prototype - awesome! - now we should begin identifying the highest value pieces to reimplement with better practices, so that we can scale the team and product effectively". You as a manager at a slightly more mature startup: "What, you want to rewrite? No, everyone knows rewrites don't work! Just hire up and keep moving fast." Experienced eng lead after a few months of burning out on a miserable project: "I have better options for this, here is my resignation." Board member after another few years and lots of turnover: "It seems like we're no longer able to execute because of all our technical debt. You have been a great manager for this early stage of the company, but now we need to bring in the mature company professionals. Thank you for your service." end scene I do not even claim that this is a bad outcome. It really is important to execute quickly early if you are going to have any chance of success. I have made the mistake of being too slow too early. But path dependency is also a big deal, and there is rarely (never?) an obvious bright line point at which it is clear that the time is right to up the professionalism game. It is not hard to get into a situation where the team is spending nearly all their time baling water out of a sinking ship that you're still trying to sail while competitors speed past you in newer sleeker dryer ships. I also think the hiring / turnover risk is a real problem. There are companies with good engineering practices, which make work much more pleasurable, and you are competing against them for talent. But I think this is a false dichotomy. I think there are a set of practices that don't introduce so much friction that they are an existential threat early on, but that are small steps in the right direction down the path to practices that scale well. I think it is telling that you went straight to Terraform in your example, although nothing like that was alluded to in the OP. I would agree with you that Terraform does not belong in this low-friction-step-in-the-right-direction category of practices. But I think all or most of the practices the OP actually listed do fall into that category. Code review, in conjunction with automatic style fixing (which most languages have tools for now), is low friction and has immediate value. Same thing for unit tests. I do think a whole end-to-end testing setup is beginning to be more friction than can be afforded, but unit tests are easy (especially if you choose languages with type systems that allow you to dispense with tests that verify the type contracts are being satisfied). Automated deployment is actually both a step in the right direction and something it would slow down your early execution to not have. There is a huge gray area, and I think it is really difficult to strike the right balance (to wit: I've never seen or personally accomplished this balance satisfactorily), but I think it is the right way of framing it. I think the right mindset for you as a manager at an early startup is not "we don't have time for that!" but "will the ROI of that be worth the time?", and that you need to do the hard work to explain that that thinking to and get buy-in from your developers.
• scarface74 6y ago
  I agree/ I work for a company that took all sorts of shortcuts that we are digging our way out of now. But guess what? If they hadn't taken those shortcuts, they would have run out of money before they found product market fit, would not have referenceable customers (B2B), would not have been able to secure funding and the company wouldn't be around today and well enough capitalized for them to pay me to help improve processes.
• bcardarella 6y ago
  I would argue the mid-level devs are more dangerous in this regard than junior devs. Mids tend to follow rules and really consider them gospel. Seniors know when and how to break those rules. Juniors are a bit all over the place in terms of outcomes and expectations.
• epstein_did_not 6y ago
  Why not hire 5 good devs for the price of 1 abroad?
• quickthrower2 6y ago
  Terraform is a bit of a straw man here. OP was talking about code reviews and testing. He did mention infra as code but not TF specifically. He didn’t say it was a startup with 5 months runway (aka a soon to be dead company?) TF is like Typescript: if you already know it why not use it? If you have to learn it on the job at a high pressure startup then maybe not. Not clear he is working at a startup or just a regular old company
• avilesj 6y ago
  I agree completely with this post. If you happen to know the runway time you got before things start to fall apart economically, I don't think there's much to argue regarding code quality (and general maintenance of the platform). In large companies, projects usually have a budget and some desired launch date. If that launch date is not met, your _worst_ case scenario is you're fired. While your best is the acceptance that It just got delayed by whatever factor affected the outcome. With small companies, your worst case is you're fired and the company could go bankrupt (or something as bad). Now, OP said he was at a mid-size company and I'd like to believe he could be a beacon of change as the company grows. Maybe all the other seniors were used to work in startups and just can't fathom doing development any other way. Bottom line is, your expectations might be off depending on the scale of the company and their current objective.