I spend a lot of time researching Cloud Native technologies. Also whilst editing the Cloud Native Software Engineering Newsletter I’m always looking for the best sources of knowledege and high quality content. Everything on the list is things I read, people I follow or books I’ve read. I’m not recommending anything I haven’t used.
By the end of this article you’ll know about the best Cloud Native resources that I’ve found to-date. Make sure to come back as I’ll be constantly updating this page!Â
Have you been thinking about wanting to write? Did someone mention to you that it might be good for your career? Or you want to write to earn some money? Maybe you just want to document your notes and share them with others?
I canât read your mind and know your motives to want to start writing, thatâs for sure. But what I can do is this: go through the fears that are currently stopping you starting to write. How do I know what these fears are? Because I have the same writing fears and I wrestle with them every day and every week.
Why building a deployment pipeline should be one of the first things you consider when creating a new product.
Recently I’ve been training for a long cycling event.
The event is a three day event where we will cycle around 70-100 miles each day back-to-back.
Itâs very much an endurance event and for all my adult life, Iâve been a strength athlete competing in strength sports that are maximal exertion. It couldnât be much more of a polar opposite set of skills.
I sat at a Starbucks cross-legged with my laptop on my lap. I’d gone out to try and find the peace required to focus on the job application I was completing as a front-end product developer.
The task was simple: Create a demo app that connects to an API (Foursquare) and shows the results.
As I sat there putting the finishing touches on the demo (you can actually still see it here) I had a realizationâŚ
Since I'm a big fan of getting real practical about the skills required to build digital products, lets take a look at how exactly we are going about finding the product/market fit for Splitoo.
We’ve been working hard over the past few weeks to put together finishing touches to the UI design. Whilst it’s not perfect, and with many more ideas to come, the product is starting to come together.
However, in the workplace, it isnât just programming knowledge that we programmers need. Learning programming is an essential part of our work â but it’s not everything.
The authors of iconic programming books had remarkable careers, but it wasnât just their coding knowledge that made their careers noteworthy. They were well-rounded experts and we should strive to emulate that quality as well.
We were struggling to get our features out into production. There were lots of defects and firefighting. All this and the company was but a few months old. What was working here going to be like in a year? We were all staying as late as we could and even working weekends to try and fix issues that would appear, seemingly, from nowhere. It was hell.
As programmers, we have a lot on our plates. Understanding the newest technology, the business, navigating politics in the business and in our teams, and all of the tools, languages, and everything else that comes with the territory. It is overwhelming.
When it comes to making improvements, it’s easy to be in favor of our own personal development over that of our teams. Choosing to focus on gaining personal skills over improving the output of the team or the business. After all, these improvements are a managerâs responsibility, right? Possibly. But this type of thinking can backfire on us if we’re not careful.
Why? Because, ultimately, we get paid for the value we deliver to our business. So if we want more pay, more recognition, and ultimately a better career, it makes sense to keep an eye on what the business wants and needs, not just our own personal development. That’s how our checks are paid and how we keep a roof over our head.
This type of thinking can seem somewhat counterintuitive, and maybe even scary, as we’re focusing on areas that feel outside of our control.
For success, it isn’t the programming knowledge you or your team members have at present that matters most. Nor is it how many years of experience we have.
It’s how we work together, how we approach problems, and most importantly, how we learn. Michael Gerber said in the most eloquent way I have seen in his book The E-Myth: âContrary to popular belief, my experience has shown me that the people who are exceptionally good in business aren’t so because of what they know but because of their insatiable need to know more.â
