I read this article looking forward to the complex bespoke code to be ripped out and deleted - but the author clearly grew as an engineer in a way I didn’t expect:
> Sometimes that’s just how it is. The devops saying “Cattle, not pets” is apt here: code (and by proxy, the products built with that code) is cattle. It does a job for you, and when that job is no longer useful, the code is ready to be retired. If you treat the code like a pet for sentimental reasons, you’re working in direct opposition to the interests of the business.
A lot of code is fun to write. A lot of problems are fun to solve. But a business, especially a startup, needs to stay razor focused. My entire career is effectively to sit in meetings and tell young, passionate engineers not to build things. It’s a bit depressing, but it’s also vital.
A good engineer can solve any problem with clever code. A great engineer knows what problems aren’t really problems and probably an XLS download link updated daily would have been fine.
> My entire career is effectively to sit in meetings and tell young, passionate engineers not to build things. It’s a bit depressing, but it’s also vital.
This was the single most impactful thing I learned in my early career. I was building out monitoring systems for an in-house service we hosted on site. My boss wanted to buy some small utility to keep tabs on some minor aspect of our environment. I was a bit offended -- I could have written that myself and here he was paying someone else to do it!
He asked: "How long would it take you to write and test this?"
Me: "Probably a week. Maybe a bit less, maybe a bit more if I run into something tricky."
Him: "Okay. This tool will cost us $500 to buy. What's your hourly pay rate for 40 hours?"
With this I achieved enlightenment. I've never again built something at work that I could buy cheaper.
> This tool will cost us $500 to buy. What's your hourly pay rate for 40 hours
This argument makes sense, but I worry that it’s a bit short-sighted. There are a lot of metrics that are hard to quantify where it might end up better: for one thing, I’ve found that integration costs and maintenance of integration of third-party systems are routinely underestimated: I’ve implemented “buy” for various systems where the work to integrate was essentially the work to build. The cost of learning a proprietary toolset rather than developing experience with open tools. The cost to the industry as a whole when something like AWS or React becomes the unreflective default choice.
Its extremely short sighted. The cost is much more than (hourly wage x code hours).
There is ongoing maintenance cost that no one considers. I've never seen a project that gets built and just sails off for eternity with no maintenance or bugs. There will be times when the libraries or frameworks that built the underlying tool need upgrading. The requirements of the job might change even slightly and need a change in the code because custom tools are always built to only solve the narrow problem.
There is also the overhead of the fact that this junior developer will inevitably leave in 6 months and now someone who has never seen this project before has to pick it up to fix it, which means it will take even longer.
Plus that ignores the fact that if a developer tells you it will take 40 hours it will actually take 80-120 hours.
When you buy, the tools you buy are designed to be integrated with. They have support teams that will help you, and ongoing maintenance. Plus the tool is going to be more robust because it was built and used by many different companies with slightly different requirements. Plus someone else's developers will keep it up to date for you so you don't have to.
Internal tools are almost never worth it unless a pre-existing tool literally doesn't exist which happens when you are either solving insanely complex problems or insanely niche problems.
> When you buy, the tools you buy are designed to be integrated with[...]
This makes me question if you're speaking theoretical, or actually have any practical experience.
I've been part of about a dozen "buy it" projects now, and so rarely they've been "designed to be integrated with. A lot of the time it's deeply legacy systems that have a half-hearted api slapped on top to check that box, but once you start using it you notice that everything you want to do somehow requires contacting the vendor first.
Which dovetails into an issue that, although vendors will give you the impression that their system is well tested and widely deployed, it all too often ends up being a lie. We've had quite a few instances where vendors have sold us what turned out to be something they were still building.
> the tools you buy are designed to be integrated with.
Until they change on a whim and force you to spend hours rebuilding your integration for negligible benefits. And then there’s the good old “change our vendors every five minutes because the last one wasn’t quite right”
If your company isn’t making money from the product then whoever owns the copyright is irrelevant.
Good engineering is building the stuff that adds commercial value to the business and buying the stuff that only adds support to the stuff that adds commercial value.
In this instance, monitoring falls into the latter category. It’s not a business differentiator.
Is it any more shortsighted than using the "open tools" in the first place? There will be integration costs and maintenance of integration with open tools. You may not be able to pay anyone for support issues because those people may not provide the sort of customer support you expect when you pay someone.
The integration costs were part of the 40 hours. The trouble is you haven't avoided them by paying the money.
Open tools also tend to have a longer life, because a community survives even as members come and go, but one boss decides that a product isn't sufficiently profitable or the company gets bought out by a competitor and now it's discontinued and you have to start over.
And the open tools often end up with more transferable skills down the road: e.g. learning to deploy to AWS only helps with AWS; learning to deploy to k8s lets you be productive in a lot more situations.
> I’ve implemented “buy” for various systems where the work to integrate was essentially the work to build
I've felt this way before, but I didn't realize that I haven't factored in the risks of actually building it. I was comparing real world integration effort with an estimate, influenced by my experience of integrating with a working product.
Common sense applies, but in general I'm terrible at giving estimates unless I've done something very similar before.
Sure it’s shortsighted, but we’re all shortsighted, that’s the human condition. We can’t know all ends, which is why experience and judgement matter. The worst thing you could do is handwring over it though. Gather whatever data you can quickly leveraging the extent of your current expertise, make a call, implement and learn.
> (from the article) - Having Excel in the browser was a useful solution, but the problem wasn’t showing spreadsheets in the browser: the problem was getting a specific UI delivered to the right users quickly.
> (from the above comment) - A good engineer can solve any problem with clever code. A great engineer knows what problems aren’t really problems and probably an XLS download link updated daily would have been fine.
I saw the bullet list further down the substack page and it's still not good enough for this level of requirements gathering. Those questions describe the scenario, but asking them would not have arrived at this simple solution. Checklist thinking is a crutch and just overcomplicates the problem. All the signals here were organizational and social, and not a matter of improving a process.
This should be obvious, but people who are not involved with implementation details can't answer questions about implementation details.
"Just make it like Excel" is a super low quality answer from someone who has a completely different set of objectives. The only way forward would have been to consult with someone closer to the actual users and counter-argue from there. What's missing here is the courage to recognize weak assumptions and deliberately avoid writing any code until enough details are pinned down to get to an agreement from all parties, not just say yes to the person "in charge".
> "Just make it like Excel" is a super low quality answer from someone who has a completely different set of objectives. The only way forward would have been to consult with someone closer to the actual users and counter-argue from there.
The only contact we had with "actual users" was over WeChat because they were on the other side of the planet.
> What's missing here is the courage to recognize weak assumptions and deliberately avoid writing any code until enough details are pinned down to get to an agreement from all parties, not just say yes to the person "in charge".
Uber was pathologically bad in this sense. There was no time to get details pinned down. We had a product to ship in two weeks for non-technical stakeholders. If we didn't, the stated consequence was millions of dollars in losses to the business. Throwing up your hands until you get product clarity when you know you can solve the problem as-is is a great way to find yourself with a PIP.
Nah, that's why you have product managers. I would have talked to this stakeholder for an hour and realized the solution is not to build another excel.
You don't reject it you understand what the problem is and design the solution and explain it to them.
I'm sure this entire team didn't need to exist in the first place but that's what you get when you only have a business person and the Dev team they hire.
A PM here would have saved the company what, $5m per year?
The second team I was on at Uber fired (with a capital F) six (6) PMs in five months for pushing back on product requirements that came from the CFO. For whatever reason, engineering rolled up to the CTO and product for this team rolled up to finance. The solution for disagreement? Pips!
Exactly, in 2016 there was several off the shelf options for doing the exact same thing. It’s a perfect example of a young engineer feeling a huge accomplishment from reinventing the wheel, and then realizing the clever solution wasn’t actually worth anything like the effort required to create it.
I had a long conversation to convince someone not to go down that path in 2006, and I am sure someone’s going to do it in 2026.
Pausing to think: I wonder how someone else solved this exact problem is such a huge part of how you grow as a developer I wish schools would focus more on it.
I would say what you talk about is experience. To have an experience, you must go this path to realize what to not do. It feels like a catch 22 kind of thing.
Doing it well comes down to experience, but doing it at all comes down to asking which of your unconscious assumptions are hard requirements. Nobody is actually saying you have skills X, Y, Z, which you must use to solve this problem, which is a huge difference from how schools prepare people for the workforce.
Experience certainly helps, but last time I checked, schools are supposed to teach you how to use reference tools (reference manuals, company listings, search engines...), and how to use them well - a pretty fundamental skill of being an engineer ?
I'm not really sure what you're saying, or what the criticism is, if it is one - but shortly before the bit you quoted OP links the code on GitHub: https://github.com/WebSheets;
And you can't really conclude they made a poor implementation choice on a report of completing it successfully (albeit too successfully even, too much of Excel implemented, and then fixed by removing that (how do you do that to your XLS download link?)) on time within a short deadline.
The takeaway is supposed to be 'don't get too attached to your code', which in some circumstances (not this one) might mean 'don't succumb to NIH syndrome, use an XLS download link', but that's not the whole.
Any time I identify a fun and novel problem I get suspicious. Generally, programming should be mundane and you should be solving problems that have been solved thousands of times before. If something looks new it's more likely you haven't correctly identified the problem you're solving.
Short term yes, but long term, life's too short. Pursue FI, especially if you're a craftsman, so you can work on what brings you joy, without an expiration date.
"Cattle, not pets" may be a good way to run a business, but not your life.
A great engineer should be both good and great. I do a lot of ‘great’ stuff at work, but that won’t help me to get into my next gig unless I also code a lot and don’t lose my skill.
> Sometimes that’s just how it is. The devops saying “Cattle, not pets” is apt here: code (and by proxy, the products built with that code) is cattle. It does a job for you, and when that job is no longer useful, the code is ready to be retired. If you treat the code like a pet for sentimental reasons, you’re working in direct opposition to the interests of the business.
A lot of code is fun to write. A lot of problems are fun to solve. But a business, especially a startup, needs to stay razor focused. My entire career is effectively to sit in meetings and tell young, passionate engineers not to build things. It’s a bit depressing, but it’s also vital.
A good engineer can solve any problem with clever code. A great engineer knows what problems aren’t really problems and probably an XLS download link updated daily would have been fine.