What I’m thinking about

There’s a quote that’s been on my mind for some time now - “Writing code and building software are two different things”. We have a great amount of resources for the former but few for the latter. And while you can read the docs or the specs of a technology or language, there aren’t that many resources about applying them at scale or architecting around them.

There are numerous getting started guides for React but little information on how to structure a non-trivial application. Plenty of resources about Express, yet most of them stick to the MVC pattern. Plenty of posts about Serverless and solving isolated problems using that stack but little about complete cloud native applications and the thought process around them.  The same goes for design systems.

I guess it’s up to each company to find out the best architecture on its own. After all no two problems are the same. What works for one may not work for the other and needs vary from industry to industry. But if we go beyond the specific business problems, the underlying technical challenges are not that different.Despite everything all tech teams face the problems of scalability, structure, state management and abstractions. But maybe formalising the solutions around them would limit creativity.

A book worth reading

Accelerate - It was recommended to me by a close friend whose company swears by it. In contrast to other technical books this one is relatively short so you can pack it for the Christmas holidays. If you’re not that interested in the business sections, power through the first part and it will grab your interest.

A video worth watching

Avoiding micro services mega disasters - it’s a favourite talk of mine which I go back to every now and then. It’s about a team that goes on a journey to create a new product using the popular micro services architecture. The whole initiative turns into a spectacular fiasco as in the end the website doesn’t even start. It’s a great example of how architecture isn’t the only thing that needs to change to create a successful software product. The team processes and engineering culture need to shift as well.

A quote worth pondering

"The value of a prototype is in the education it gives you, not in the code itself." - Alan Cooper

This email was sent to <<Email Address>>
why did I get this?    unsubscribe from this list    update subscription preferences
Code Philosophy · 7000 Ruse · Ruse 7000 · Bulgaria

Email Marketing Powered by Mailchimp