I've Been Writing Code for 37 Years...
I started coding in the eighties.
I remember using Logo to draw flowers and BASIC to create interactive quizzes with a friend.
I learned touch-typing and pascal in high school.
I studied data structures & algorithms in university for an undergraduate Computer Science degree. We worked primarily in C and C++ and I learned just enough perl and lisp to be dangerous.
I graduated from university in 1998 two years after Palm, Inc released the first Palm PDA.
At that time, 25 years ago, I was already working as a web developer.
The first web browser I ever used was Lynx, a text browswer, back in 1994. The first browsers I wrote code for were Netscape 3 and Internet Explorer 3. Back then Opera was the new disruptor and Firefox, Safari, and Chrome did not exist yet. This timeline of web browsers maps out how the browser landscape has evolved over the years.
I was debugging cross-browser CSS before SCSS, SASS and browser-based dev-tools existed. I learned that background-color is your friend because it doesn’t change the box size. I devoured A List Apart, dabbled in the Zen Garden, and ranted about web standards and usability. I cried when Eric Meyer and his family lost Rebecca. I sent John Resig a Firefly DVD box set for his work on Firebug and jQuery.
By 2004 my attention had turned to desktop apps and backend code.
I taught myself C# and worked with .NET for 15 years. I discovered git and Test Driven Development. I dabbled in Ruby. I became a certified PRINCE2 Project Manager.
During that time I found my way into build and deploy automation:
- Why write code if you can’t ship it?
- Why ship it yourself when you can write code to do that?
A few years ago I became a YAML engineer. I wrote chef cookbooks to manage load balancers and server configuration. I taught myself golang to write terraform providers and build command-line tools.
Now I use terraform to build and manage cloud infrastructure in AWS and typescript to build React apps.
Here are some lessons I’ve learned along the way:
- Learn Your Fundamentals
- Should I Learn Data Structures and Algorithms?
- Learn to Ask for Help
- Ship Early and Ship Often
Learn Your Fundamentals
These days we have so many libraries and tools to help us do our work. You can get a lot done by copy paste. But the more you learn about how things work the better you will understand all the abstractions built on top of them.
As an example example, I have worked with git since 2005 and taught git since 2012.
When I teach git, I teach it through the command line.
“Why do that when there are so many graphical tools?”, you may ask, and “Who uses the command-line anyway?”
Did you know that git started as and still is a CLI tool? In fact, git is only a CLI tool. All graphical versions of git, from IDE plugins to standalone tools, call git commands under the hood.
When you want to understand your tools, you have to pop open the hood and learn a bit about how they work.
With git that means learning the command-line. You can start with my series on git fundamentals
Should I Learn Data Structures and Algorithms?
Working in IT it is helpful to learn a few of the more common data structures (e.g. a Stack, a Queue, a Linked List, and a Tree). They come up a lot.
Being able to recognize them will help you, yet you will rarely need to implement data structures from scratch.
Far more useful is to learn to recognize these patterns so that you can search up more detail when you need it.
You may find visualizations like VisuAlgo and Map, Filter and Reduce - Animated to be useful.
Learn to Ask for Help
Asking for help is a cricital skill that will unlock your potential to learn and grow.
Practice putting your ego aside to focus on the work.
Put yourself into situations where you will make mistakes in front of others.
Become as comfortable talking about what you don’t know as talking about what you do know.
There is a balance between waiting to long to ask for help and not waiting long enough. Ramón Huidobro wrote a great blog post called Asking for Help Effectively as a Software Developer that explores this balance in detail.
Ship Early and Ship Often
Look for ways to ship code, early and often.
Shorten your feedback loops to learn faster.
Put your code in front of people as soon as you can.
Deploy your code and put the working app in front of people.
Welcome feedback.
Don’t wait for code to be perfect.
Press publish before you are ready.