Getting better at something is a skill. I’ve learned that the hard way over the past few months. Deliberate practice is key to improvement and I’ve been doing a whole lot of deliberate practice.
Most of my time is split between brushing up on data structures and algorithms, working on portolio projects, or applying for jobs. It has been exhausting, but I am improving at an unprecedented pace.
Writing Go code has been eye opening in a lot of ways. I hardly understood concurrent design and rarely bothered with pointers (even when the language I used supported them). But Go emphasizes these things. I know the applications and cost of passing by value or reference. I understand channels and goroutines and why they are such powerful tools.
The next step is to use these concepts and cement them in my mind through a project. I’ve been playing with a toy blockchain implementation and that has been fun, but I really want to create a web app utilizing microservices. Something that can scale through concurrent design.
Anyway, I’m rambling a little bit. The point of this post is just to document some of my improvements as I go.
As of right now, I need to brush up on my front end skills. I plan on trying out ember.js and if that isn’t a good fit I’ll go back to React/Vue/Svelte. In addition to that, I want to learn FastAPI and write some more Python. Go is great, but I need to keep those Javascript and Python skills up to date.
It’s pretty funny that I would write about specialization just after writing a post about wearing every hat.
But I’m not talking about that kind of specialization. I’m talking about picking a set of tools and really building my proficiency with them. As I’ve explored development and programming for the last 15 years or so, I’ve mostly done it because I was curious. It was a hobby of mine to track down the newest, shiniest things and play with them.
In this sense, I was always trying out something new. I’ve written pet projects in dozens of programming languages and I’ve used hundreds of different libraries. Unfortuantely, this method doesn’t really lend itself to mastery. If I want to really get good with my tools, I need to keep using the same ones.
So — I’ve decided that my backend tool of choice is Go. Go is a very powerful programming language with out of the box features that I love. There’s no need to download a framework to get going with Go. The standard library has most of the tools you need to create a strong backend design.
However, Go can be a little overkill in some scenarios. In those cases I want to utilize Python with Django or FastAPI. Python is a great language for productivity. I can get things up and running super fast, and I love this. In addition, Django is pretty opinionated framework. This means that it is sort of an “all tools included” approach. Everything I might need for a web app should have some native implementation in Django. If Django is too heavy weight, I have plenty of other options, too.
Finally, on a related note, I’ve also decided to really buckle down and master PostgreSQL. It’s an incredibly powerful, open-source, DBMS and basically an industry standard.
I’m still making up my mind about my front end tools. Ember.js looks promising and server side templates are always an option. In the future, I’ll likely consume an API with react or something, but that’s for later. For now — mastering Go and Django.
I’m learning that approaching software engineering from a professional perspective is requiring me to stretch myself in every direction. I have to understand every aspect of the process from dev ops to marketing.
I’m working with a good friend of mine and both of us have hammered in some of the systems/frameworks we’ll be using going forward. Some of these were picked simply because they are popular industry standards. Others were picked because they felt comfortable.
For now we’ve been tackling the planning phase. Specifically, we’ve begun creating our product backlog via the scrum framework. In this backlog, we define every requirement we need to fulfill to reach our “product goal.” That product goal is our end product. The website or application itself.
On a side note, git is a different beast when I’m not using it on my own for personal projects. I’ve even contributed to a few open source repos, but using git “properly” on a big, collaborative project will take some learning. But that’s the whole point.