This post was originally published on Siv Scripts
The best laid schemes o' mice an' men
Gang aft agley
I started a new job as a Mathematician / Software Engineer at a Chicago-based healthcare startup in October. It's my first proper development job and I could not be more excited.
I get paid to write code. It's pretty awesome.
Had always thought I would work in data, maybe transition into a data engineer role. But here we are. I'm working on a team of ~10 developers building a clinical decision support web application.
Guess this change isn't entirely out of left field; I had started to dig deeper into software engineering best practices over the past few months. Became fascinated by the different methodologies and frameworks that facilitate the production of good code. As a self-taught developer, I desired formality. There's only so much I could absorb by reading about other people's experiences and working on open source projects after work.
I needed to get my hands dirty and get some real world practice writing code as part of a team. Thought it would be good to experience the process-based workflow of a structured Agile/Scrum development environment; to understand the pain of working (effectively) with legacy code; and to have no choice but to write tests for the code I ship. And, preferrably, have those tests be written first.
It's only been a month, but I think I made the right decision. In one of my first commits, I made a change and took time to refactor code to increase readability ala Code Complete. Got a shoutout during code review. That felt awesome! Software Craftsmanship FTW!
I will say that I find myself constantly studying after work and on weekends so that I'm not completely useless, but I wouldn't want it any other way. Coding at the edge of my abilities will increase my skills exponentially.
While I eventually plan on going back to data, let's hold off thinking about when. Right now I'm enjoying life and want to stay on Mr. Bones' Wild Ride.
The main reason I took a backend developer role was to level up my dev chops. This means many different things such as writing clean code, being able to identify and correctly apply design patterns, recognizing anti-patterns (code smells), and, of course, learning the tools of the trade.
Over the past couple of weeks, I've started transitioning away from the friendly confines of VSCode and iTerm2 into the magical world of Vim and tmux. Even though I'm fairly proficient with a graphical IDE, I thought it was worth investing in tools that enable me to work as fast as I think.
By switching to a terminal-only development environment, I hope to reduce the context switching that occurs everytime I reach for my mouse or trackpad. As an added bonus, I can SSH into any machine and feel at home. No more having to set up rsync or use nano as a crutch.
- Worked my way through
$ vimtutor. It's a rite of passage.
- Enabled Vim keybindings in all my text editors (VSCode & Sublime) to get comfortable using the
h j k lmovement keys. Being in a familiar environment where I could get work done without having to Google every command did help flatten the learning curve.
- Once I was able to make the cursor go where I wanted, I watched Learning Vim in a Week. Key takeaways:
Last weekend, I installed tmux on my home machine so I could start getting familiar with how it works. My
.tmux.conf is very basic, but all the pieces are in place to enable me to learn at my own pace. I just have to make an effort to learn a couple of new things every week. Like everything else in life, it's about putting in the reps.
You're only as good as your tools so it's worth making an investment into optimizing your workflow. We're developers and we should always be tinkering with the software we use on a daily basis. It doesn't have to be Vim and I'm not suggesting everybody go out and learn it. But do take some time to learn your tools and the plugin ecosystem of your IDE.