For context, a bit about me:
- I've been developing software since 2008. I'm in my ninth job in that time, including some short-term contracts. I'm currently a consultant so I've worked with several different clients.
- I've switched primary programming languages twice and tinkered with a few others.
- I didn't study programming in college, but learned independently through books and the mentoring of a good friend.
- Over the years I've come to focus mostly on the server side of web development.
- I've carefully chosen my career path to avoid overwork and stress.
- I've had a happy career so far. :)
Advice for Interviewing
- Be transparent. Show what you know, but never bluff. You'll either be caught and probably rejected, or get a job you can't do.
- If you don't know something, show that you're curious to learn. Curiosity is a great trait in an industry where there's always more to learn.
- Ask questions. You're evaluating whether you want this job. What affects that? Hours? Pay? Culture? Chances to learn? Travel or lack thereof? Culture? Ask specific questions and use the answers to choose or to negotiate.
Advice for Learning
Read books
A systematic tour of a subject, written by an expert and crafted with the help of editors, will help you learn a subject much more completely than random Googling.
Also, if you find a great book, look for others by the same publisher; they probably have high standards.
Take notes
Use any system that's low-effort.
Eg, I have a giant, plain text (markdown) log.md file where I put short entries on things I learn.
I also have many topic-specific files, but if I don't have a clear topic to put something under, I just slap it in the log.
I keep my note files in a private Git repo with lazy commit messages like "More notes".
When I started out, I kept notes in Google Docs. Do whatever you like, but bonus points if it's searchable. Many times I've learned something, forgotten it, needed the info, and found it in my notes.
Also, taking notes as I learn a new subject (including questions that occur to me) helps me cement what I'm learning.
Keep bookmarks
As I find helpful articles, I bookmark them.
Crucially, I use a bookmark tool (in my case, pinboard.in) which lets me add one or more tags per bookmark, such as postgresql or kubernetes.
Like my notes, this has often let me get quickly from "I think I once read something about that" to having the info in front of me.
Consider shelf life
To stay employed in technology, you need to maintain a stockpile of useful knowledge. When you learn, you add to it. When you forget things, it erodes.
But there's another force at play.
Every piece of technical knowledge has a shelf life. When it's fresh, you can use it to build things and get jobs. When it spoils, you can't. And knowledge spoils at different rates.
For example, when I think back to everything I learned around 2008:
- Everything I learned about jQuery is obsolete.
- Some of what I learned about JavaScript is still relevant.
- Almost everything I learned about databases, HTTP, shell scripting, Linux, and Vim is still useful.
In general:
- Knowledge about a language will outlast knowledge about a framework.
- Knowledge about a tool that's used by everyone will outlast knowledge about a tool that's used by few people.
- Knowledge about an old tool that's still being used will outlast knowledge about a new tool.
- Knowledge about algorithms and math will last forever and be useful in every language and framework.
It's OK to learn trendy things, especially if job searches show you that those skills are in demand. But also invest in learning things that will serve you for years to come. If you do, your store of knowledge will keep growing, not spoiling faster than you can store it up.
Consider Memorization
Every skill is cumulative and has basics which must be memorized.
When you start learning to read, it takes effort to recognize which shape is which letter, then later, to sound out a word. To read like an adult, you have to master these skills so thoroughly that you do them without thinking. You can never enjoy literature until the act of reading becomes effortless and automatic, so that you can't even look at a word without reading it.
It's the same with music. You can't focus on the finer points of expressive guitar playing unless the shapes of chords are already in your muscle memory.
I sing reasonably well but read music poorly. I once sang tenor in a college choir which rehearsed for months before a concert. In our last two or three rehearsals, one of my professors of music joined us and stood next to me. I was amazed to hear him sing the part perfectly on the first try. When I asked him about it, his response made clear that where I saw a rising note for my part, he saw the chord progression being formed by all the parts and the piano together, all at a glance. I was sounding out "S-U-N"; he was reading astrophysics.
In programming, there are things that would be pointless to memorize, and things that you need to know cold. The difference depends on how often you do them and how basic they are to other skills.
Be on the lookout for knowledge that would make you more productive if you had it memorized. For those things, consider making flash cards in a "spaced repetition" tool like Anki.
General Advice
Think in hourly rates
You can and should calculate an hourly rate for a salaried job. The basic questions are "how many hours do they want me to work per year?" and "how many dollars in benefit will I get per year?" Divide to get the rate.
Doing this calculation has several benefits.
First, it gives you a fair comparison between job opportunities. For example, if two companies pay the same salary but one expects 40 hours a week and the other 80, the overtimers pay half as much per hour. If one company gives more vacation time or time to learn new skills, that's fewer hours in the year that they expect you to work. If one company gives better benefits, add their value to the gross salary.
Second, it it lets you know what you'd need to charge if you were consulting independently, where you have to pay for your own benefits and time off.
Third, it helps you see the value of investing in your career. Suppose you're making $50 an hour. A tool that can save you an hour a week would give you $2,600 a year in value. A book that could get you a 1% raise would give you a $1,000 value the first year, which would probably compound with future raises.
For hours, you may have to ask pointed questions. "We don't track hours" is evasive. "Most people work 40-45" is clearer. "Everybody works 40 and then we tell them to go home" is very clear.
For benefits like insurance, make a rough guess at their dollar value. If you had to buy the same coverage yourself, what would it cost? (Non-Americans, don't look so smug.)
Watch out for coupling
Developers love loose coupling. If you couldn't change your application's credit card processor without also changing its database, that would be a nightmare.
We fight this. We define interfaces and behaviors and contracts and protocols and standards. We deploy microservices which can change independently in containers which can run anywhere.
Yet many developers happily couple their investments with their employer by accepting stock options as payment or retirement plans which require vesting.
I'm no expert on stock options, but I know that "unicorn" companies are rare. And I've heard that the fine print on stock options can hold nasty surprises, even if the company does well.
If you start your own company, you take on all of the risk and all of the reward. If you work purely for a salary, you opt out of both. It's valid that there are options in between. In general, I think that the "expected value" of options should be considered as zero.
But for me, the overlooked issue is coupling. If you want to be able to change your job without changing your investment or vice versa, watch out for these things.
Make your career serve your life
Your first job can be hard to find. After that, it gets easier. That means you can be choosier.
You can use that leverage for whatever you want: to maximize your income, to minimize your stress, or to work on things that matter to you. Personally, after an early experience of being expected to work overtime, I've made it a point to find jobs that don't require that. I've probably sacrificed some money, and that's fine with me.
My wife, my kids, and my faith (I'm a Christian) are more important to me than work.
Build learning into your work
I started programming as a hobby. I was working full-time and learning in the evenings. This was fine, because my wife was also busy; my time was free.
These days, we have three wonderful kids, and most of our energy goes to them. I don't want to take time from my family to work overtime or to study.
If you think your life might take a similar turn, consider how you can build learning into your work week.
I once worked with (and became friends with) James Gray, who, at the time, was contracting three days a week and taking the other two to learn. I found that inspiring, and set a goal to find work where I could learn during the work week.
These days I work at DockYard, a consultancy which employs me as an expert and has an interest in maintaining my expertise. Every Friday, DockYard lets developers spend time learning. Having time to learn at work feed my curiosity and frees me from needing to study on nights and weekends. And it vastly increases the hourly rate I'm being paid.
Seek nice people
Once, I was moved from one working group to another. My work didn't change, but I was suddenly much happier because I was appreciated and liked my colleagues more. That stuck with me.
Don't confuse work with family
Some companies want to say they're like a family. They're not.
A company can't function like a family because it has to make money. When times get tough, it has to choose: lay some people off, or run out of money and lay everyone off. And if it chooses layoffs, it has to choose who.
A company can't be a family because you get hired and retained based on your perceived merit.
This is not because companies are bad. They may be nice companies run by nice people. But they aren't families.
You don't lay off your grandma. You don't fire your kids.
A company can't treat you like a family, so don't treat them like one. Do good, honest work. Be kind. Make friends.
But coworkers will leave, managers will change, and jobs will end. Don't get too attached. And be ready to move on.
Consider the long term
The best job security is marketability.
Scratch that. The best job security is not needing a job.
Budget. Get out of debt and stay out.
Save for retirement.
Start now. This goes doubly for every dollar your employer will match - don't turn down that money.
Enjoy your career, do good work, and be able to quit when the time comes.
Happy coding!