Throughout my career, I’ve learnt, usually the hard way, the importance of getting the foundations of whatever I was working on right. Or at least as right as possible. I learnt how fundamental it is for setting your project — and by proxy, your team — up for success. I’d argue it’s one of the most important things you should pay attention to. Getting the basics right is notoriously hard due to the inevitability of changing requirements, external factors, etc. which is why dedicating a reasonably large amount of time to figure out the foundations is so invaluable.
Failing to lay down your base stones properly will cost you dearly down the line in lost engineering time, project delays or even lost business — your customers are likely to stop paying for the house of cards. Sure, you can always run around the clock after the fact and start realigning things in panic like a headless chicken but at that point, you’re chasing a train rather than driving it. Once you get the foundations right maintaining them is at least as important. You should be continuously revisiting them and making sure they are still serving you well — I like to think of this activity as a regular exercise or practice that makes perfect. In fact, there are many examples of very successful athletes who religiously stood by similar principles: get the basics right.
One of the best examples of this was the legendary basketball player, Kobe Bryant. Kobe moved to Italy with his family when he was about 6 years old. He started out playing for a kids’ Minibasket team. The rims were shorter and the court was smaller than in America. As he remembered, “At practice, there were no scrimmages, ever. We learned only the fundamentals. Passing, screening, moving off the ball, shooting - all the basics," he said. “And if we did scrimmage, we’d scrimmage full-court, no dribbles allowed. So that set the foundation for me for how I came to understand the game, and how I now teach the game.”
He continued in the same tone throughout his whole career. Mastering the basics was what set him apart from others. One of the stories as recollected by his teammates was about how Kobe would go through one of his intense warm-ups. He would do the most basic footwork for half an hour, doing the stuff routinely taught to high schoolers, but he would be doing it with the most intense level of effort and focus. When asked why “the best player in the world does all these basic drills” he would respond with his usual level of confidence:
“Why do you think I’m the best player in the world? Because I never get bored with the basics. I never get bored with the basics”
Famous American chef and travel documentarian Anthony Bourdain who found his success in writing books and making critically acclaimed travel shows that inspired millions never reached the level of cooking fame many of his peers did. As a cook, he earned his badges by working for some of the craziest restaurant owners in NYC [1]. Bourdain famously regretted, after graduating from CIA (not “that” CIA), “the biggest mistake of his professional life:"
“…never going to Europe, doing an apprenticeship under one of the great chefs to learn, practice the basics and excel
In one of his bestselling books[1] that earned him a place in stardom he describes what makes professional chefs successful:
“What most people don’t get about professional cooking is that it’s not all about the best recipe; it’s about the line cooking — the real business of preparing the food — which required consistency… mindless unvarying repetition of doing the same task over and over again”
When describing one of his [famous] chef friends, Scott Bryan, he would mention how much emphasis he would put on getting the technique right.
“One of the lowest points in his career was in a kitchen in California when he would be going home ashamed and a little angry because “the technique wasn’t great and needed more practice”.
So he decided to practice more. He wanted to master the basics. Without that, there was no enjoyment he could draw from his craft and he knew how that would project into the food he was cooking for his guests.
If you ever ask a Senior engineer what’s probably the most important thing to get right [or pay the most attention to] when starting a new project chances they’ll say something like data model or some variation of database design. They will probably follow with something like the architecture and then, finally, they’d talk about code design, frameworks, engineering practices, security etc. The main reason for this ranking is the data models and architectures are notoriously hard to change once they’re “live” serving your applications; the same goes for good engineering practices which have a great influence on your ability to deliver great outcomes for your customers. Code itself on the other hand, whilst still important to get right, tends to be more amenable to modifications.
Databases [and data models] are very intricate things to deal with. They are at the core of a huge majority of online businesses. Literally. APIs are just cute “pipes” opened for the API consumers to peek into your database. You open them too much or too little and you’re screwed — once the API is open to the public it becomes notoriously hard to change. Especially when you amass a reasonably large number of users. The corollary is, that stable, well-designed APIs are what your customers and API consumers crave.
You can (and should!!!) always version your APIs but that doesn’t free you from the database hassle — in fact, changing API versions often goes hand in hand with changing data models. And getting that right can be challenging even for the most experienced engineers. Database changes often require complicated migrations — one of the most underappreciated tasks software engineers have to do! Some of the migrations I’ve done over the years would warrant changing the name of the task to migrainetions, but I digress.
Some teams I worked with had a particularly good talent for breaking databases: breaking the ACID properties in database transactions? No problem! I don’t know what they teach in database courses nowadays that would lead any reasonably qualified person to commit these data crimes but there I was, my jaw dropped in disbelief, contemplating my life choices.
Broken engineering teams usually find a “workaround” for these issues because fixing the actual root cause is hard, usually laborious and always at the cost of doing something else instead — the irony is not lost here. These teams end up performing some sort of data syncing tasks regularly every time the inevitable data divergence appears. Sometimes the data would diverge so much that fixing it would take days and would preoccupy several, usually the most senior people on the team. And then we would pray our database wouldn’t get trashed whilst getting rectified and serving the regular traffic.
In an ideal situation, someone on our team would notice this before our customers did — in the worst case, it would be the customers puzzled about discrepancies in API responses. Or worse, they would discover some discrepancies in their invoices. Needless to say, this made our engineering teams look like a bunch of amateurs — hardly a badge of honour if you care about your craft and success of your organization.
Some of the best engineering teams I’ve been fortunate to be a part of invested a lot of time and effort in their engineering practices early on and then kept continuously revisiting them. Code changes, database [models] change, requirements change and people come and go, but good engineering practices should outlive all of these changes:
- solid CI pipelines minimise the build times
- frameworks and code style guides prevent a lot of unproductive PR review discussions
- code generation prevents wasting engineering time on tasks the machines are better equipped with
- monitoring setup that enables faster root cause analysis for bugs, etc.
All of these and more (don’t forget about security!!!) play a decisive role in your organization’s success and even to a large degree in the job satisfaction of your engineers.
And it goes beyond engineering. Getting [and maintaining] the foundations right is ever so important to any organization through activities and behaviours we learnt to call “the culture”. Brian Chesky’s famous blog post[3] is one of many manifestations of how important establishing and maintaining company culture is for the success of any organisation.
Conclusion
Fundamentals have different forms and shapes in different fields. In basketball, it’s [probably] footwork, movement and shooting and in cooking it may be cutting meat and vegetables and doing it with extreme consistency like a well-oiled robot. In software engineering, IMHO, it’s usually the data model, architectures, and great engineering practices! Identifying these foundations and getting them as close to the ideal as possible will serve you well down the line. Never stop revisiting the basics regularly. It might feel mundane, laborious and boring and getting them right might be hard — if it were easy everyone would be doing it — but they’re worth investing your effort in. Learn to fall in love with them. They’re the key to your success.
[2] Kitchen Confidential https://en.wikipedia.org/wiki/Kitchen_Confidential_(book)
[3] Dont fuck up the culture https://medium.com/@bchesky/dont-fuck-up-the-culture-597cde9ee9d4