Engineering as Art
Something many people don’t know about me is that I studied art right until I was 18. I was never technically brilliant, but what I had was creating thinking and plenty of ideas.
Sometimes, I struggled to put them into practice. Which is much like my career in software as well.
When you think about software engineering, art is not be the first thing that comes to mind. But actually, this article by David Grizzanti proposes we are artists.
And much like David, I have finished reading Rick Rubin’s book ‘The Creative Act’
And much like David, I was reading it thinking just how many parallels there are between creative work and our work in the software engineering world. Especially as you move to higher level roles.
If you follow some practices that the more typical artist follows, you could be surprised at how that affects your day to day work.
Adopting a beginner’s mind, being open to new ideas, getting outside your comfort zone or trying out new mediums (I’m looking at you Python). These things help cultivate a skill set that will set you apart.
For an incredibly motivating look at our industry, check out the article below.
Building Production Grade Software
Ah, the words ‘production ready’. Something I talk about all. Of. The. Time. It’s great to show a new technology or service using a simple hello world example. But where we fail as an industry is moving beyond that.
Once I have my hello world, how do I apply that to my big enterprise application with 10,000+ users?
CICD, observability, performance tuning, resilience. There are many more things to think about than writing code.
So when I came across this article from Allen Helton on, I was surprised to ask the same question. What actually is ‘production ready’ software?
With an excellent analogy and tangible examples, Allen shows exactly what production grade actually means. As well as pointing out a few key architectural ‘-ilities’. And I agree with lots of his points.
That’s not to say you will never write another POC. I just ask that you keep things like performance, maintainability, operability and resilience in the back of your mind as your building it.
Doman Driven Design in the Real World
And to round out this issue, I wanted to share a post from one of my favourite new writers I’ve discovered in the last few weeks. A mentor recommended hila to me, so I had to dive straight in.
In this article, Hila covers the practical aspects of Domain Driven Design. As a long-time advocate of DDD (the big blue book was the first software book I ever read) it’s great to see it applied in a real world setting.
I LOVE, how the ways of working at Augury are wrapped in ‘when → then’ statements to explain exactly when to use certain concepts.
I also LOVE, how the core ideas of DDD have been tweaked and changed to fit the specific needs of an organisation.
DDD is a fantastic book, and a fantastic framework for thinking about software. But the ideas need to fit YOUR organisation. And these slight changes are a great example of how DDD can work for you.
It also touched on one of my favourite topics, application integration. And patterns you can apply as you build cross-cutting services and shared interfaces you can use across your entire organisation.
It even gives you an example of how to take an existing integration point, and refactor that into a different integration pattern.
Brilliant stuff. Follow Hila once you fit the link below.