Hey I'm Lou! I'm a Cloud Software Engineer From London. I created Open Up The Cloud to help people get their start and grow their careers in cloud. I edit the monthly Open Up The Cloud Newsletter which I think you'd really like. You can find me on Twitter or LinkedIn , I'm always happy to chat. When I'm not writing you can usually find me picking up heavy things and putting them down, or riding two wheels (sometimes with an engine, sometimes not).
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.
It looked something like this: Become extremely knowledgeable in a given programming language until eventually you become a senior programmer.
Once you’re a senior programmer, you ride out the rest of your career as a programmer. Or you make a leap out of the technical world and into a strategy- or management-focused role.
For many programmers, this is a hard decision. Programming is what we love and we don’t want to lose our hard-earned skills. As programmers, we’re often very aware of how quickly our skills fade when we’re not in the business of putting out code anymore.
But it doesn’t have to be this way. There is another option that allows you to straddle both areas of the so-called softer and technical side of the profession.
At some point in your programming career so far, you might have been asked to “coach.” Most programmers get into the field to write code, and often before we know it, we end up in a leadership role, almost as if by accident.
Only a few months into my first job I remember telling my boss that I felt like I was teaching a lot. I’d like to say it was a natural inclination towards teaching, but I don’t think that’s it. Because of the nature of the field of technology, teaching and coaching others is an inherent part of what we do. Even if we’re really new to the field.
