This post is part of a series interviewing veteran developers, asking them questions about their journey to tech mastery and sharing the advice they have for those getting started.
Everyone has a different path in life, and that’s OK! Today we’re talking to Michael de Ridder, who tells us about how getting into programming was accidental, not intentional. And that’s OK, too.
Michael has worked in software development, data visualization, data science, research, consulting, and business analysis across health care, telecommunications, radio and finance. He enjoys the challenge of combining and utilizing the relationships between different domains and technology. A big fan of travel, Michael is a proponent for the benefits of work-life balance, believing that time away from a subject allows creativity to flourish.
Let’s learn from him how even a (perhaps drunken) accident can lead to good things and valuable lessons.
What made you want to go into programming?
That’s a more interesting question than it seems. And it’s as good a time as any to say that I wouldn’t call myself a programmer. I recently heard my résumé described—in a job interview no less—as a drunkard’s journey. When the interviewer said drunkard’s journey, he definitely didn’t mean it as a negative, and in fact I took it as a compliment.
It’s true that I know how to program. I’ve programmed in jobs, during research, and on personal projects. And it’s true that I did a programming course at university.
But to answer the question of what made me want to get into programming, I can only say nothing. I kind of fell into it. And I think that’s great! The thing about programming is that it’s open-ended. There aren’t many skills out there that open up as many doors or give you as many options.
To anyone out there who wants to get into programming, follow your passion! To anyone out there who’s unsure and doesn’t know what to do, don’t worry. Let life take you where it will. I promise you that if you’re open-minded and let yourself live with change and a bit of uncertainty, you’ll have fun. You’ll even find excitement in nervousness and uncertainty.
If that’s the case, and getting into programming was kind of an ‘accident,’ what were you most worried about when you made the decision to study programming?
The biggest worry for me was—and still is—that I would be pigeon-holed.
I think it’s a problem that a lot of programmers, and engineers in general, face. It’s beginning to change with the creation of bridging roles like product owners/managers, scrum masters, technical business analysts, and the like, but generally the consensus is that a programmer can only code. Sit them behind a screen, tell them what to do, and they’ll create something elegant—but talk to them about the business goals, strategy, sales, customers, or culture, and you might as well ask a caveman.
The thought of being that person stuck behind a screen terrifies me. It’s not that I crave control—I’m happy to help see out someone else’s vision (as long as I agree with them). It’s more about the repetitiveness and the limitations it places on mentally stretching in different directions.
I can happily say I have managed to hop out of the pigeon hole, combining programming with medical research, startup competitions, data science, radio configuration, project management, business analysis, product ownership, business and technical strategy, consulting, business operations, writing, and so on. But even so, it’s a challenge to convince many people that I’m not a small gray bird.
What I’m really trying to say is that everybody is different. If you’re looking to get into programming and think the best thing in the world is trying the newest, shiniest technologies and making more and more elegant solutions, that’s amazing! I know I could never do that. If we can fuzzy-up definitions of roles like “software developer” a bit, I bet we’ll end up with a happier workforce and better products because we’ve allowed people to be themselves.
… Maybe, on reflection, I should have said that it would be going into an industry that labels me a veteran while in my 20s. That would have been much quicker and far less zealous.
We’ve had drunkards, accidents, and now pigeons. Did you ever think that you’d made a huge mistake getting into this field?
Of course! I still do all the time. But then, I would have thought that no matter what field I went into.
All I can say to anyone who has doubts is that it’s normal. Try not to dwell on them. Everyone has worries; the difference is how much you let them impact your life and hold you back.
Sometimes the best thing to do is just to forget the past. I can’t tell you how many times I’ve been called a goldfish (that one was for the list of metaphors ;-P). Think about the difference between updating legacy systems and building something new from scratch. If you forget the past, then you’re free to try whatever you like—whether that’s in programming or not. You don’t have legacy holding you back.
Mistakes are part of life. Imagined mistakes even more so. What turns an imagined mistake, like “I shouldn’t have gone into programming,” into a real mistake whether or not you hang onto it.
If you haven’t forgotten it all, what advice would you offer to people considering a career change to programming?
This advice applies to anything, not just programming: Give it a go!
By that, I don’t necessarily mean quit your current job, go back to school, and start again. One of the biggest lessons I’ve had driven home in the past few years is the importance of quickly testing your assumptions with as little effort as possible. If you’re looking to get into programming, this lines up with another piece of wisdom that will serve you well: A lazy programmer is a good programmer. That sentiment can be translated to this: Don’t reinvent the wheel unless you have to, and even then, see if you can modify work that’s already been done. When they invented tires, they didn’t reinvent the wheel. They modified what they knew and added a new technology to make a smoother ride.
But back to giving it a go and keep testing assumptions. My advice is to find a way to quickly and easily “try before you buy.” Maybe a friend has a website idea you can try to build a prototype for. Or maybe you know some programmers you can talk to. Heck, reading this post and the others in this series (that are much better than mine) is quickly testing some of your assumptions.
What programming reference materials can you not live without?
This one may sound obvious if you’ve looked into programming, but websites like Stack Overflow.
If you feel a bit of guilt about using answers on those sites, I’m here to dispel your fears. Go back to my comment about being lazy and not reinventing the wheel. These sites are like having access to an almost unlimited supply of expert colleagues you can go to for help. Most of the time, you don’t even need to ask because your “colleagues” have already asked and answered the questions. Inserting it into your code isn’t cheating. Instead, it’s showing that you understand the desired outcome and are doing what you can to get there.
To be a bit more practical in dispelling fears of copying or plagiarizing, it’s good practice to comment on the code snippets saying where they came from. If you look through code repositories, you’ll see attribution everywhere: from <person> <url> and modified from <url> changed the inputs.
If you look hard enough, you’ll even see the really honest programmers: copied from <url>, not sure exactly how it works (lines 1, 8-15, and 21 confuse me), but tested thoroughly. There’s no shame in saying you don’t know. In fact, it shows that you’re giving it a go. You’re living with uncertainty. In fact, was that a bit of a drunk stumble I just saw?