4 ms·

As a dev i've always known my hunch when it comes to compromises. Never let the business team ruin your experience building cool rock-solid code. I'd rather res

As a dev i've always known my hunch when it comes to compromises. Never let the business team ruin your experience building cool rock-solid code. I'd rather resign than to compromise anymore. I know there should be a sweet spot between "perfect" and "working". Even a junior can pull-off a "working" app. But when it starts to scale, all those hasty bad decisions will bite your ass. Never skip planning, plan as long as you need. Nowadays i start coding only after i have 100% visibility into what i'm building: diagrams, dependency graph, schemas, types and data structures, documentation, user flows, everything. As the say goes: if i have 24h to chop a tree, i'd sharpen my axe 23h. And we haven't yet taken into account infrastructure, devops, ci/cd, security, releases, logging, and all sorts of tooling. I need around 2 months just for initial planning, setting everything up and laying out the codebase structure.

username_my1 4y ago
I partially agree here. if a component is core to your strategy or product then by all means make sure it's rock solid. but if you're iterating on your product and you don't know which feature is going to be used then don't waste time perfecting it. we put together in days products that we shutdown in 3 months, we would have never been able to move at such speed if we took our time plan, design, develop ... and business people do come with a lot of things that go nowhere (depending on your company sales culture of course and product maturity)
throwaway2016a 4y ago
I would say a related point to that is: don't skimp on unit and integration tests. It's easy to rush code out but tests will force you to think through it and give you a way to quickly test if a change is a breaking one. But as a counter point, early in a product lifecycle you don't even know if the product you are building is what you are going to find a market fit for. So spending a lot of time getting the tech perfect is sometimes a waste. It's a constant calculation of balancing the risk of not scaling with the risk of taking so long you never get to the point where you can scale.
- andreisbc 4y ago
  In my case, I haven't really considered integrations tests, as I didn't have the time. Only the bare minimum unit tests "it('should render or shouldnt fail')"
- TruthWillHurt 4y ago
  Tests are for teams of contractors that don't know how the product works. The talented person that built the thing knows exactly what a change will require, and how to test it before pushing his code. Don't be an enterprise too soon.
  - throwaway2016a 4y ago
    > Tests are for teams of contractors that don't know how the product works. The opposite. Tests are for people who know exactly how the product works. It's very hard to write good tests if you don't understand the product (or at least your piece). I really hope you are being sarcastic. Tests when done properly speed up development and make your product more robust and resistant to breaking changes. For a proof of concept that will never see production, sure, by all means don't write tests. But in my 15+ years in CTO and Principal role at smaller companies, the most expensive projects with the most downtime are always the ones without tests. Tests make software cheaper not more expensive. And the ROI isn't even that long... all it takes is for two to three iteration / release cycles.
tnolet 4y ago
Good luck with that trying to find PMF and first 100 customers. Later stage, I get it sort of. Seed and A series you will kill your company by being too slow. Waterfall does not work for this.
lbayes 4y ago
I apologize if this sounds harsh, but I can't see the /s anywhere and I want to clarify for others. This post outlines how to destroy a new (or any) business. There will never be anything approaching 100% clarity between different people talking about a thing that doesn't yet exist. We all have to see it and feel it in order to truly understand it. This experience almost always leads to creating new, better ideas, discarding old ideas and digging deeper on others. That's all before we even leave the building and learn from customers. I shudder to imagine trying to get a start up off the ground and needing to wait 3-6 months for the first commits only to then have to argue about change orders with my eng team.
10x-dev 4y ago
Thanks for sharing your thoughts here. I think it's useful for us to get a glimpse into your thought process and start a discussion. Though I empathize with the overall desire, you sound inexperienced to me, as in, you might have had some failures that you attributed to lack of planning or business decisions, etc, but you haven't learnt from successes, because some of the stuff you're saying is just extreme counterproductive wishful thinking to the point where it sounds like trolling. For example, 'building cool rock-solid code' is typically not a business goal or at best, a nice to have. Developers are hired to solve a business problem. If the code doesn't solve the problem, you're wasting precious resources. 'cool code' is a personal choice. Compromising is essentially a trade-off like any other, and it requires careful deliberation in every context. Your opting to not compromise by default means that you're introducing friction in the team, in the business relationship and potentially affecting the life of the business, not to mention that it's a 'us vs them' mentality when you're supposed to be part of a team to deliver a product together. Your reasoning about hasty decisions biting you is also backwards. Notice how you're just assuming that a product will start getting enough users to need to scale. Guess what: like most products, the product you worked on was actually not that great, didn't have a good product-market fit and if you hadn't spent all that time polishing and planning the cool non-junior code, you might have saved everyone months of time. Also you go from 'never skip planning' to 'take as long as you need'. Those are 2 extreme approaches. It turns out that a little planning goes a long way. You can come back and iterate on the plan. No plan is going to be perfect from the start, because you don't have all of the information available to you when you start a project. As you develop a project, you get more information on hidden requirements, user expectations, non-functional requirements and various other metrics that you couldn't have thought about ahead of time. What you are describing is the waterfall approach to software development and the only way it doesn't fail is if the domain and the product are very well understood (e.g. "build a grep clone in Rust"), but most products aren't well understood ahead of time, only in retrospect, so it's a constant back-and-forth between acquiring new understandings about the product and applying them in practice by changing what's already there. It requires your code to be flexible, not 'cool' or 'rock solid'. Consequently, you will never get 100% visibility into what you are building. If you find yourself thinking "gee I know exactly what we are building" you are setting yourself up for disappointment when 'the business people' pull the rug under all your diagrams and schemas and types that you spent months designing instead of getting a usable POC out the door asap. Honestly, it's just a phase you're going through. Once you get burned by your current approach a few times, you'll internalize the need to avoid either extremes and you'll start looking for that middle ground with each project. I know it because I went through the same phase in my career. Good luck!
fourseventy 4y ago
No offense but this is awful advice for a startup.
- deleted 4y ago
  [deleted]
- andreisbc 4y ago
  Please read my comment below. You are right, but we cannot generalise.
throwaway787544 4y ago
> if i have 24h to chop a tree, i'd sharpen my axe 23h. It doesn't get sharper if you sharpen it indefinitely. You'll be wasting time and metal. There's always a point of diminishing returns. Just get the tree down, because another task is waiting.

username_my1 4y ago

I partially agree here. if a component is core to your strategy or product then by all means make sure it's rock solid. but if you're iterating on your product and you don't know which feature is going to be used then don't waste time perfecting it. we put together in days products that we shutdown in 3 months, we would have never been able to move at such speed if we took our time plan, design, develop ... and business people do come with a lot of things that go nowhere (depending on your company sales culture of course and product maturity)

throwaway2016a 4y ago

I would say a related point to that is: don't skimp on unit and integration tests. It's easy to rush code out but tests will force you to think through it and give you a way to quickly test if a change is a breaking one. But as a counter point, early in a product lifecycle you don't even know if the product you are building is what you are going to find a market fit for. So spending a lot of time getting the tech perfect is sometimes a waste. It's a constant calculation of balancing the risk of not scaling with the risk of taking so long you never get to the point where you can scale.

andreisbc 4y ago
In my case, I haven't really considered integrations tests, as I didn't have the time. Only the bare minimum unit tests "it('should render or shouldnt fail')"
TruthWillHurt 4y ago
Tests are for teams of contractors that don't know how the product works. The talented person that built the thing knows exactly what a change will require, and how to test it before pushing his code. Don't be an enterprise too soon.
- throwaway2016a 4y ago
  > Tests are for teams of contractors that don't know how the product works. The opposite. Tests are for people who know exactly how the product works. It's very hard to write good tests if you don't understand the product (or at least your piece). I really hope you are being sarcastic. Tests when done properly speed up development and make your product more robust and resistant to breaking changes. For a proof of concept that will never see production, sure, by all means don't write tests. But in my 15+ years in CTO and Principal role at smaller companies, the most expensive projects with the most downtime are always the ones without tests. Tests make software cheaper not more expensive. And the ROI isn't even that long... all it takes is for two to three iteration / release cycles.

tnolet 4y ago

Good luck with that trying to find PMF and first 100 customers. Later stage, I get it sort of. Seed and A series you will kill your company by being too slow. Waterfall does not work for this.

lbayes 4y ago

I apologize if this sounds harsh, but I can't see the /s anywhere and I want to clarify for others. This post outlines how to destroy a new (or any) business. There will never be anything approaching 100% clarity between different people talking about a thing that doesn't yet exist. We all have to see it and feel it in order to truly understand it. This experience almost always leads to creating new, better ideas, discarding old ideas and digging deeper on others. That's all before we even leave the building and learn from customers. I shudder to imagine trying to get a start up off the ground and needing to wait 3-6 months for the first commits only to then have to argue about change orders with my eng team.

10x-dev 4y ago

Thanks for sharing your thoughts here. I think it's useful for us to get a glimpse into your thought process and start a discussion. Though I empathize with the overall desire, you sound inexperienced to me, as in, you might have had some failures that you attributed to lack of planning or business decisions, etc, but you haven't learnt from successes, because some of the stuff you're saying is just extreme counterproductive wishful thinking to the point where it sounds like trolling. For example, 'building cool rock-solid code' is typically not a business goal or at best, a nice to have. Developers are hired to solve a business problem. If the code doesn't solve the problem, you're wasting precious resources. 'cool code' is a personal choice. Compromising is essentially a trade-off like any other, and it requires careful deliberation in every context. Your opting to not compromise by default means that you're introducing friction in the team, in the business relationship and potentially affecting the life of the business, not to mention that it's a 'us vs them' mentality when you're supposed to be part of a team to deliver a product together. Your reasoning about hasty decisions biting you is also backwards. Notice how you're just assuming that a product will start getting enough users to need to scale. Guess what: like most products, the product you worked on was actually not that great, didn't have a good product-market fit and if you hadn't spent all that time polishing and planning the cool non-junior code, you might have saved everyone months of time. Also you go from 'never skip planning' to 'take as long as you need'. Those are 2 extreme approaches. It turns out that a little planning goes a long way. You can come back and iterate on the plan. No plan is going to be perfect from the start, because you don't have all of the information available to you when you start a project. As you develop a project, you get more information on hidden requirements, user expectations, non-functional requirements and various other metrics that you couldn't have thought about ahead of time. What you are describing is the waterfall approach to software development and the only way it doesn't fail is if the domain and the product are very well understood (e.g. "build a grep clone in Rust"), but most products aren't well understood ahead of time, only in retrospect, so it's a constant back-and-forth between acquiring new understandings about the product and applying them in practice by changing what's already there. It requires your code to be flexible, not 'cool' or 'rock solid'. Consequently, you will never get 100% visibility into what you are building. If you find yourself thinking "gee I know exactly what we are building" you are setting yourself up for disappointment when 'the business people' pull the rug under all your diagrams and schemas and types that you spent months designing instead of getting a usable POC out the door asap. Honestly, it's just a phase you're going through. Once you get burned by your current approach a few times, you'll internalize the need to avoid either extremes and you'll start looking for that middle ground with each project. I know it because I went through the same phase in my career. Good luck!

fourseventy 4y ago

No offense but this is awful advice for a startup.

deleted 4y ago
[deleted]
andreisbc 4y ago
Please read my comment below. You are right, but we cannot generalise.

throwaway787544 4y ago

> if i have 24h to chop a tree, i'd sharpen my axe 23h. It doesn't get sharper if you sharpen it indefinitely. You'll be wasting time and metal. There's always a point of diminishing returns. Just get the tree down, because another task is waiting.