Writing is really beneficial for exploring the problem space.
Many times I’ve confidently thought I understood a problem, started writing about it, and come away with new critical questions. These things are typically more visible from the abstract, or might not become apparent in the first few release milestones of work.
I’m reminded of a mentor in my career, who had designed an active/active setup retroactively for a payment gateway. He pulls up a Lucidchart and says “this diagram represents 6 months of my life”.
They’re not always necessary or helpful. But when they are you can save weeks of coding with a few days of planning.
I had a boss who had a math degree. He'd map out the flow from start to finish on a whiteboard like you see mathematicians on TV/movies. Always had the smoothest projects because he could foresee problems way in advance. If there was a problem or uncertainty identified, we'd just model that part. Then go back to whiteboard and continue.
An analogy is planning a road trip with a map. The way design docs most are built now, it shows the path and you start driving. Whereas my bosses whiteboard maps "over-planned" where you'd stop for fuel, attraction hours, docs required to cross border, budget $ for everything, emergency kit, Plan A, Plan B.
Super tedious, but way better than using throwaway code. Not over-planning feels lazy to me now
Sure, everyone has a plan until you get punched in the mouth; however, that saying applies to war, politics, negotiations, but not coding.
Yes I have to second that. MLJ.jl is also written by a mathematician and the API is excellent. Truly well thought-out.
(If you think “why does MLJ.jl have so few stars?” please keep in mind that this library was written for the Julia language and not for Python. I honestly don’t think the library is the cause of low popularity. Just wrong place wrong time.)
And for them to be listened to, what is independent on how well they communicate; and for them to be aligned with the most powerful stakeholder, what is almost never the case; and for no big change to happen in an uncontrolled way, what powerful people nowadays seem intent on causing all the time.
If you create the plan like a mathematical formula like my boss did, the evidence becomes irrefutable... like a mathematical proof. The article does mention that the plan is communication tool.
> however, that saying applies to war, politics, negotiations
It’s not even an argument against planning. You’d be a fool to go to war without a plan. The point of the saying is that you’d be a fool not to tear up your plan and start improvising as soon as it stops working.
It is kind of an argument against overplanning though, because if your plan that you spent considerable time creating becomes irrelevant, you wasted a lot of time
That assumes the plan itself is the only useful output from the time spent planning. Even if the plan itself isn't used, the time spent planning means you examined the problem thoroughly, and raised questions that needed answering. Taking the time to think about those questions in order to give a coherent answer is, in and of itself, worthwhile for answering the question later, even if that part's never actually written down.
True, I agree 100%, and that's why I chose to say 'irrelevant' to imply that there was nothing useful about it inherently for those cases. Most of the time, at least in coding, there was probably something useful that came out of it, even if you had to scrap the plan. At the very least, some sort of learning more about the problem space. In the case of war, however, if you lost the war because you over-planned (such as planning one thing very very intricately instead of having several rough plans that leave room for some improv), I'd argue that there probably aren't any residual benefits to celebrate
I had to do this for a patent application, and likewise found it very useful for identifying holes in my thought process or simply forcing myself to do the functional design work up-front and completely.
It was also great for brainstorming about every feature and functional aspect you can imagine for your product, and making an effort to accommodate it in your design even if it's not MVP material.
In my experience it applies to coding when you have any reliance on third party libraries or services and don't have an extensive amount of actual real world experience with that technology already.
If you have unknowns, then your planning process starts with, "let's figure out how to use this new technology." And that process can involve a bunch of prototyping.
Having to make a choice between "make a design document" or "do prototyping" is a false dichotomy. They're complimentary approaches.
My boss would take a piece of data/input and run it through the entire process. It's a string data here, converts to number here, function transforms it here, summarized here, output format there... You wouldn't run into data type issues or have an epiphany that you're missing a data requirement.
I the book How Big Things Get Done they analyze big and small project failures and success and end up with something along the lines:
1. Spend as much time in planning as necessary, in the context of mega projects planning is essentially free, maximize the time and value gained in planning.
2. Once you start execution of the plan, move as fast as possible to reduce likelihood of unforeseen events and also reduce costs increases due to inflation, interest paid on capital etc.
+1 for "How Big Things Get Done". It changed the way I run projects. I got lucky in the sense that I was able to convince my corporate overloads to allow us to have separate Discovery and Delivery goals, on the premise that discovery is cheap and delivery is expensive (the former significantly reduces risk of the latter) and we show our work. Discovery goals come with prototype deliverables that we're ok not shipping to production but most times lay the foundational work to ship the final product. Every single time we've found something that challenged our initial assumptions and we now catch these issues early instead of in the delivery phase.
We've fully embraced the "Try, Learn, Repeat" philosophy.
I agree writing is beneficial. But I also find this works with coding. And they go hand in hand for exploring in my experience.
And in the end a good PR has a lot of writing too and has this effect. IMO this sort of well documented draft PR serves as a better design proposal because pure writing causes you to forget important constraints you only remember when you’re in the code.
Agreed. You can write prose or implementations or tests beforehand and I don't think it matters too much which you choose, just as long as you give yourself a phase 2 for incorporating the learning you did in phase 1 and put a reality check of some kind in between them.
The only problem with having the draft being implementation is that maybe you'll get pressured into shipping the draft.
I’ve had to ship the draft a few times in my career. Usually when the actual code would have been weeks or months more of work (draft has poor architecture, while a proper architecture would have been just as much work as the draft). Twice it was due to showing a demo and a decision maker in the audience said “we can sell this tomorrow” or something to the same effect for that org. In one case, we ran a simple a/b test as a proof of concept on whether to pursue the idea further and it added an extra million bucks a year in revenue. Nobody wanted to wait for a proper implementation. All that code is still in production, slow as shit and nobody wants to fix something that isn’t broken.
If you have a draft, keep it to yourself. Use it as a personal reference when writing the design, or share snippets. Other engineers will realize you have a draft, business people won’t.
> In one case, we ran a simple a/b test as a proof of concept on whether to pursue the idea further and it added an extra million bucks a year in revenue.
I'm with the people who decided to ship this. The organization will need to fund more maintenance than they would if they waited, but that has real costs. And "keep your 1mm/revenue idea to yourself" doesn't sound like a healthy engineering culture either.
Heh, yeah, that is a special case though. Most people don't work on things that has that kind of impact. If it might, I would suggest going against my own advice.
The time spans for doing it properly or shipping are maybe a bit muddled here, but if you can make a million dollars by shipping something now, you should probably ship it now. If the code is that bad (ie can end up costing way more to maintain than fix) then you should afterward immediately fix it. Side benefit is you’ll probably learn a lot about doing it right from the prod system.
Oh we tried to fix it and never succeeded. As soon as other teams found out about it, they started using it too. To be honest, had we waited to do it right, we potentially could have made even more money.
I'm not sure what you mean by "should". If your job is to build things that aren't going to fail in ways that later end the company or hurt people, then finding ways to keep the:
> But we could make an additional million next quarter if we ship it now
...crowd in check is probably what you should be doing.
I agree that LLMs capabilities with a language are going to be extremely relevant. Community, API consistency, and whatever other factors that are going to increase LLM usefulness will decide the popularity of languages in the coming years.
I’m not sold on the importance of static typing though. I’ve had great results with Ruby and Python with 4o, o1, and to a limited degree Copilot.
One of the biggest benefits of Ruby is how simple testing is. The language is so dynamic that mocking/stubbing and intercepting or whatever is dead simple stupid.
So the “static types prevent you using LLM hallucinations” does not hold for me. I’m going to write tests covering the method (which the LLM will probably help with), and I’m going to get an undefined method error.
It's very evident this is the case if you generate similar JavaScript or TypeScript.
The types mismatching can really help you spot mistakes early on instead of at runtime, plus with the LLM generating trivial boring types is very straightforward.
The same effect is visible in Rust too and you'll quickly catch APIs that don't exist or that are being used incorrectly - albeit LLM understanding of Rust is really bad compared to other mainstream languages
Respectfully, both of our diets are totally fine, and I don't need your opinion to let me know that. Any biomarker you might like to use tells us that we're fine; our weight is the only number that is "outside the norm", and while sure it's a measure of overall health it's not the only one or even the best one.
To be clear, being obese is dangerous in the long-term. Your biomarkers being okay now doesn't mean you're good to go. Obesity increases your risk of pretty much everything bad. That doesn't mean you're magically unhealthy, but certainly your risk is greater.
That doesn't mean you need to change anything or that you're weak or whatever people might say. I do tons of unhealthy stuff that are fine for the time being. I drink for one - that's gonna catch up to me.
Also basic biomarkers are not a complete picture of your health. Obesity puts stress on the body in a variety of ways, some of which might not show up until it gets to a threshold point. For example, strain on joints.
BMI is a shit metric and must be taken with a grain of salt.
If you take a not so tall person with a large muscle mass and sub 10% body fat, you can still end up in the severely overweight / obese range.
Because muscle is way more dense than fat, and we should factor in for bone mineralization and bone weight in those who do resistance sports as well.
So take BMI = kg/m2 with precaution, as there better metrics such as waist-to-height ratio.
You know if you are a BMI outlier. It's not interesting to discuss outliers as they are rare by definition.
BMI is a fine metric for describing a population's general health when it comes to weight. The actual reason the metric exists.
There are exceedingly few folks with 10% body fat and a BMI of 30. They tend to be clustered around professional athlete or bodybuilder circles. Again, not interesting to discuss these things outside of niche circles. Those that are outliers know already, due to the work they put in to be such.
No one is walking around with a BMI of 30 and happening to accidentally be at a healthy weight due to low body fat percentage/high lean muscle mass and not knowing it.
Agree the DB side is overstated. These particularly suck though in ruby on multithreaded servers (eg puma), where N+1s are constantly giving control of the GVL to another potentially greedy thread. I’m sure python multithreaded servers will suffer similarly.
I manage at a lower level, a team of developers. I’m a big fan of stating a clear goal and letting the developer/team decide how to tackle. I may have suggestions, I may veto proposed solutions if I have legitimate problems with it, but ultimately I want them to be the drivers. In my experience they take ownership, are more motivated, and it helps them grow. They’re more likely to solve little problems on their own and only involve me as needed.
Spot on with cost, as with everything you have to be pragmatic.
Tests are great for:
* High risk items (large consequence when it goes wrong)
* Documentation
* Weird unintuitive things
We had a C# project recently that needs to detect changes between a DTOs properties. At implementation, all the comparisons would be done over value types, but if someone added a reference type that didn't properly implement equality this would silently fail (likely for months). Good case for adding a test that ensures the change detection works for all properties.
For portable non-concentrate, Mighty by Storz and Bickel is hands down the best device I've used. The engineering is flawless: amazing battery life, extremely durable, easily replaceable wear/tear parts, use while charging, fast heat up times, a poker built into the base of it... I could go on. It was pricey but I've had it 4+ years, with no signs of decaying battery life or any non wear/tear part replacement, despite a lot of use and a lot of abuse.
One thing I don't understand is why the CC does charge a fee to the defrauded party. I mean, I'm not doubting this is what happens, but I don't understand why.
The merchant is in the best position to prevent fraud, so it makes sense that they bear the cost of fraud. You can't charge person who committed the fraud, because you don't know who they are (unless the merchant has video footage or something). Charging the cardholder is illegal. If the merchant bank bears the cost then they would just be redistributing the costs back to some other party and we would be back to square one.
That makes sense. But in the case of online transactions (where you can't ask for id), how can the seller prevent the fraud? It's there any due diligence expected? Or how can they send themselves? Is this just an example of "the cost of doing business"?
>I often have this weird fear that I wont accomplish anything in my life like it is some sort of personal failure.
Completing a big project, setting a new weight lifting or running PR only leaves me feeling empty. I've come to realize fulfillment, for me at least, is in the journey; accomplishment is merely a memento.
I have exactly the same feeling. It always felt alien to me people talking about feeling good after finishing some project, unless the thing was so painful that they're glad it's over. What is exciting to me is actually the challenge of the problem-solving.
Many times I’ve confidently thought I understood a problem, started writing about it, and come away with new critical questions. These things are typically more visible from the abstract, or might not become apparent in the first few release milestones of work.
I’m reminded of a mentor in my career, who had designed an active/active setup retroactively for a payment gateway. He pulls up a Lucidchart and says “this diagram represents 6 months of my life”.
They’re not always necessary or helpful. But when they are you can save weeks of coding with a few days of planning.
reply