Embrace your weirdness and stop worrying

Once you’ve reached the point where you’re a proficient programmer with a good understanding of a useful tech stack, you’re now faced with the sisyphean task of Keeping Up with New Tech.

Polishing your professional skills becomes trendsspotting, starting with daily Hacker News browsing sessions to find out what’s going to be the new hotness, and then making sure you know everything about it. Or it is really? Frameworks and tools keeps multiplying like rabbits, and anybody claiming they’re up to date is profoundly delusional: something new probably came up as they’re saying it.

I’ve been thinking about how futile it is to feel like you’re missing out on something great in today’s tech landscape. There was an era when you could know everything about a programming language, but this time is long gone. What you really need is to stay sharp and keep exercising that learning muscle so you’re ready when something hard gets thrown at you. Every software has its quirks, and your job is to learn them and be productive, not to be perfect the first time you’re touching it. You’ll never be 100% ready for a new task, so they’re no point in sacrificing all your nights and weekends to this.

Let’s face it: as an interviewer, would you be more interested in a candidate that messes with the insides of old NES games for fun, someone involved in their community with a blog or open source software, or yet another person which only has a bunch of buzzwords to offer? If you try to be close to the trend in the hope you’ll stay relevant for the hiring market, it’ll only make you identical to everything else, and it will lead you to burnout. Good teams include a mix of people with different ideas and interests, and not just an army of clones.

I’m leaning more and more toward the idea that you should embrace your weirdness, run with it and have some fun. I’m prone to being too serious at times myself, but learning a bit more about making game or electronics is not a life-long commitment. It’s merely a good excuse to go out of your comfort zone and learn a new and interesting skill. Besides, you never know what could come out of it…

Writing a book: how to work on many projects

After quite a bit of pondering, writing and editing, I shipped the Learning as a Software Developer book last week. The whole process took about 6 months to complete, so I had time to experiment with a few ways to work. During that time, it was important for me to keep the blog going and still have time for technical learning and my various homestead-y hobbies. So, in that case, I was in for a marathon, not a sprint.

Spoiler: making a commitment to write regularly was the best way to make progress.

I’ve also tried a batching approach to the problem. The idea was to write a few blog posts in advance the first week, then spend the next week working on the book, and finally do a bit of technical learning. It was working decently at first and I WAS able to batch a few posts in advance, but then life happened and I was only able to write a little bit for the book before having to go back to blog posts. Fail!

Making sure I’d work a bit on everything each week was the best way to make sure I’d keep moving forward. It kept everything fresh in my mind, so I had less catching up to do to go back into the flow and start writing. To limit context switches, I’d pick ONE thing to work on every night instead of jumping from task to task.

important-writingI’m aware this makes me less effective than batching, and that it takes more time to complete some projects, but this way I don’t lose steam and burn out. Right now, I’m living in manager space and not in maker space: I don’t have time to focus intensely on a project for hours every day, so I have to sprinkle important projects here and there to make sure they get done. If I space out working on each project too much, I’ll wake up 6 months later without having published a new blog post or written a newsletter.

Relating to this, I also had to hone my ability to get to work immediately (or at least faster) since I’m working during the gaps in my day. I only have a block of a few uninterrupted hours in the weekend if I’m lucky, so I can’t lose 2 hours getting started every time.

The key here is to have a task primed and ready to go, or at least a well-defined process. For example, to write a blog post, I generally write a draft in one go, and then edit the next time, so I’m either starting a new blog post or completing one.

Finally, what helped me is that all those tasks are similar enough to fall into the same habit. I changed my blogging habit to a habit of writing and coding using the same cues and rewards, so I’ve not lost a habit that took some work to build. It took quite a while to ship everything this way, but in the end it was worthwhile and allowed me to ship the first version of the book to you.

Getting over myself and doing things the easy way

During the summer, I usually spend a lot less time working on the computer. I’m outside instead, taking advantage of the short Canadian summer to garden and soak up sun while it lasts. When I do work on something, I keep it light and try new technology that piqued my curiosity just for the fun of it.

Poule-smallThis year, we also started keeping chickens, so my new project is to automate our chicken coop. The goal of this system is to automate the lights, and act as a weather station to collect information about the conditions inside and outside the coop. All of this will be controlled by a web application accessible from a smartphone. Ultimately, I’d like to automate the doors too, but it’ll require a bit more work.

It’s a fun project that allows me to dust up my neglected hardware skills. It’s been a few years since I’ve seriously worked with hardware: when I was last involved with microcontrollers and embedded computers, Arduinos were just starting to get popular. Since it’s been so long, it’s been interesting to see how my thinking has evolved.

Some background…

I have been a professional programmer all my working life, but I’ve studied electrical engineering AND programming. One could believe that all that theory from school would be useful, but it used to slow me down a lot: every time I would start a new project, I would first try to plan out how everything would go.

I would then start worrying about all the potential problems that could come up, get sucked down the rabbit hole and eventually quit working on it. If I didn’t knew much about electronics, I could have hacked things together until they worked and be satisfied, but I had the curse of knowing just a little bit too much.

Also, since I did spend a few years studying this, I felt an obligation to follow the “one true way” and make my own life as hard as possible. Why use Arduino and existing libraries when avr-gcc works just fine? Libraries are for wimps! If you’re not pouring over 100+ pages of datasheets, you’re not doing real electronics!

Getting over myself

All of this is completely ridiculous of course, especially if it’s a project you’re doing for fun. I’m thankful there are standards and good practices for commercial products: I don’t want my oven to set the house on fire or interfere with my smartphone. But if you’re just looking to learn and experiment, you can’t do much damage with a 5V circuit. Maybe you’ll burn a few components, but that’s life.

Looking back, I see a lot of similarities with how people are told to learn to program or to start using a new language, cramming in too many computer science patterns and practices before getting started. Trying to learn theory without balancing it with practical work on real software is a dangerous pitfall that will stop you from progressing. If you have too many things to keep in mind at once, you’ll start worrying about how your project will collapse under its own weight because of your spaghetti code, even if you’ve barely gotten started.

In the end, you’ll stop yourself from shipping projects even if you don’t have any users yet. You’ll start believing that you must understand everything to perfection before getting started, and that no shortcuts are allowed, ever. That makes it really hard to keep learning and growing.

As a programmer, you’ll learn where you can cut and where you must put more effort with experience. This can’t be learned from books and courses, you have to see it for yourself. There is a time and place for implementing things yourself because you wish to learn more or because it’s a critical part of your project, and another for using code someone else has written and that is good enough.

Thankfully, I’ve gotten over myself and I’m now more laid back about using hardware and code other people made. For this project, I’ve been using some great open source code from the Arduino community instead of trying to reinvent the wheel, and it’s been a blast. Hopefully, I’ll bring this one to the point where I can use it!