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.
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. Today we cover a lot of topics, from whether you should go into programming or IT to being specific about what you set out to learn to the lessons you’ll never learn until you start working.
And we’re learning about all of these things from Gabriel Aizcorbe. Gabriel got into IT when he received his first 8088 at 14 years old. From then on, his whole life was about computers, programming languages, and learning more. As a project manager with PMP and agile methodologies, he gained experience in all kinds of projects in the local and international markets. He has a deep passion for data and analysis and is striving to launch a startup devoted to data manipulation and analysis while he works as DBA/BI consultant.
Let’s hear about the lessons he’s learned on his journey.
Basic logistics: Stack? How long have you been doing it?
I’m a bit of an “un-stacked” person—more a “free soul,” if you will. I prefer to mix my own tools as I need to in order to achieve a goal. But, if I had to associate myself with a stack, based on the tools I use the most I would say Microsoft stack. Either way, I have enough flexibility to change to a MEAN stack or whatever else comes along. In the end, they are still development tools.
Where to Start?
If you want to know where to start, you can take a few approaches. Of course, this depends on what you want to do in your programming career.
If you want to build games, you should learn some common gaming languages (and platforms, too). For mobile app development, you would focus more on the languages used for iOS and Android development. Is data analytics your thing? It’s pretty hot right now! And if it is, you’ll want to learn data-centric languages, plus some languages that specialize in data analysis like R.
See what I mean when I say it depends on what you want to do? But if you don’t quite know where to begin, you might look at the markets. Are you interested in learning to code because it has a good job market? If that’s your game, then you might consider using the markets as your guide.
Two points to consider:
The markets are always changing.
Some languages are in demand because knowledge of those languages is uncommon.
Also, you can ask around. Of course, if you ask five different people, you’ll get five different answers. But, you can always take the ones that are mentioned more frequently and start there. I’ll share my own list and see what others have to say on the topic, too! Continue reading “What Languages Should Every Programmer Know?”→
As programmers or aspiring programmers, we often focus on the technical skills we need to build software. We work on improving our programming skills, picking up new frameworks, or reading technical books to improve our knowledge of computer science.
However, those technical skills will only get us so far. As with most careers, we need to expand our learning and also focus on professional skills. And actually, these skills will make the technical side easier, as we’ll have more clarity on what we need to do to solve problems.
In this post, we’ll go over what non-programming skills programmers need to use in our jobs.
First and foremost, we need to be able to communicate with our fellow programmers, analysts, product managers, and customers. Without clear communication skills, requirements get lost or misunderstood. As a result of poor communication, programmers might build the wrong solution to the problem. Or their solution might make things difficult or clunky for the user because the programmer didn’t understand the problem correctly.
Oh. You want to know why developers should write documentation? Fine.
Why Developers Should Write Documentation
Developers should write documentation because it makes it easier for both you and your coworkers to use your code. Well-written code is easy to read and understand. Documented code, on the other hand, is a gift to everyone—even to the coder that created it.