Becoming a better developer does not always mean being an expert in a programming language. Nor does it mean being the smartest person in the room. More often than not you will find that you aren’t an expert and you aren’t the smartest person. Work is more than just programming, it’s understanding and developing products that people will use and to do that it requires more than just a rock star programmer, it requires a person who is has the abilities to help their company succeed.
I doubt anyone subscribes to my blog or reads it regularly but do those who tune in may have noticed that I haven’t been updating as much recently. For a while I was on a good pattern of posting once a week or at least every other week. These posts where planned and structured and part of an on going process of learning and self discovery. But that changed. Where I was once learning and writing about technology and felt inspired each step of the way, I soon found that both the projects and writing became strained and obligatory instead of inspired.
When I started developing Microservices I felt like I had been missing out on a huge part of the modern technology world. It turned out that I was right. Over the past few years I’ve been trying in my mind to figure out how modern development teams run effectively. What I discovered was that there are tons of people out there trying to figure out the same thing. Many of the things I’ll write about are patterns that have been around for more than a decade, yet still many companies don’t seem to adopt them.
So you’ve built an app that runs on your machine. Great. Now what?
Obviously software is built to be used and today most of that software is being run on servers in the cloud. But sometimes it’s not. Sometimes it might be running on some old hardware in the basement of a company or maybe another developer needs to use your code as part of integration.
Whatever the case may be it would be nice to package your application in such a way that it’s guaranteed to work no matter what environment it is in.
There is a very important product that you have complete control over: you. Your skill set, your personality, your overall career is completely within your control. Those are all features of your product and it’s on those pieces that you need to iterate and improve.
Good products are successful often because they have good product managers. It is up to you to decide how you fit into the world and what people are demanding of you.
One of the most powerful things about Go is the ability to run parts of your application concurrently. This allows the application to run in parallel at times (depending on the number of cores) or continue to run while waiting for a blocked process. There are a number of concurrency patterns that allow you to structure your applications to get a performance boost.
Recently I stumbled across the “Pipeline” pattern and was able to use it to transform incoming data and aggregate the results.
People enter into technology thinking they can pursue an idea that will make them a lot of money. If you read startup stories you will find that most start with an idea, evolve into a business, become broke, rebound and make millions…. or end up being broke and learning a lot.
I’ve read these stories but I am not a risk taker. Maybe I just don’t believe in my ideas as much as others or lack the confidence to pursue them.
You should always write tests. To fully understand how to write production level applications in any language you should be able to write unit tests. Some people go to the extreme of doing Test Driven Development (TDD). TDD advocates that you should write tests before you write the code. This can be a good approach when trying to write code that can be easily tested. Yet I find that TDD is a lot like agile; a lot of people say they do it but in reality they do some sort of hybrid version.
In an earlier post I wrote about how to structure Go programs to be leveraged by both a FaaS and a standalone application. This simple application showed the power of what a Hex architecture can do by limiting the need to rewrite logic when an external resource has changed. In that example we looked at changing communication between an HTTP call from an AWS Lambda to a direct application call.
I have a terrible memory. It’s not because I don’t pay attention; there is just too much on my mind. The barrage of incoming texts, work emails, news alerts, and ideas creates chaos. Disconnecting is not an option all of the time, especially for those in the technology field, so what can you do?
It used to be when a computer was running slow or crashing the best solution was to add more RAM, expand its memory.