Thoughts on dev hiring and skill sets : Part 3 What to expect from being in product
| Culture | Hiring | Career | intermediate |
Oh, you thought the business was the focus of all these? This is for the developers. No, not "coders", not "programmers", or "testers", "quality assurance", "designers" ... Developers. The first one is something I've had a hard time learning.
1. Understand that you will never stop learning. Ever.
No one told me when I started this crazy train that it's like being a doctor, or a lawyer, or any other professional career ...without the prestige, without the generalization when I explain it to my family. First it was "I'm in computers" to at least now I can say "I'm a nerd". The tech I used 20 years ago is nothing like what I use today (mostly because, well, a lot more of it works!).
The learning never stops, it never holds still, it constantly moves, changes, adjusts, and things get thrown away, sometimes daily. Forever.
When I started, .net delegates were the new hotness. By accident I figured out what they did, how to use them and abused it every single chance I got. It was awesome. I understood what it was doing. I loved using those and there was great performance gains among others with a low amount of effort... then the next version came out. Every single one of the advantages were gone. All of them, completely gone. What was cool and slick was now "overly complicated" and was replaced. Worse, I agreed. The new way was more discoverable and friendly.
I felt like I did something wrong. I felt like I had messed up.
Why didn't I know the new version optimized for the exact thing I was doing was going to be instantly irrelevant? It's called progress. I had to throw away that idea entirely but for fun, sometimes, I'd still write one and let the tooling tell me “hey that’s dumb, do this”. Get use to that. It never stops and the rate is accelerating.
2. Don't be in it for the money or the dream
My wife’s Aunt asked me to help her daughter out -- she wanted to be a designer of websites. Admirable, I asked why, what drove her to that choice? "The money". This is the wrong reason, unless you want a terrible job. Don’t believe me? Look around, there are terrible jobs that pay just fine, and probably in every field imaginable. No doubt, most tech jobs pay well but for some of them that's it. That's all they have going for them, a nice number dump into the account on some cadence.
TV hasn't helped either. From shows, to the news, they talk about how much money a company just raised, or was bought for, or how easy it is to write a GUI interface using visual basic to track the killers IP address
3. Learn to work on a team, as a team.
If you take nothing away from any of these, it’s this : the days of sitting by yourself, making decisions in a vacuum are holding back progress. It’s far more effective when you work with someone else, a team, or multiple teams. Teams do amazing things and need to be apart of getting things done.
If you want to go fast, go alone; if you want to go far go together
I modify that slightly near the end. If you want to go far, go with a fire team.
4. Learn to solve problems, don’t worry much about the language
...unless it’s PHP. No really, language doesn’t matter that much. Pick with one and stick with it purely to learn how to solve problems instead of what package you need to install, plugin you need to apply, etc. Learn how to test with it, automate with it, etc. If this is all new, start with a “C ish” language. Javascript, Java, C# have a lot of syntax, patterns and heuristic in common, and looking at one verses the other will help make it less foreign. Otherwise, pick one you like and make senses and feels right.
5. Learn how to learn, and more importantly how to forget and re-learn
Every so often I use a different IDE. A different text editor. A different library that does the same thing one I already have. I think on my dev box I have 5 or so IDEs, 3-4 text editors and 2 things that do sql stuff. Why? It forces me to work in a different way, on purpose. This feeds back into #1, but I think it’s worth calling out explicitly.
This isn't just for software, it's really a thing for life. There's even a book about it.
My favorite is finding a different person to pair with -- and notice I didn’t say developer. Find someone with zero experience in the domain and even better if they have no idea how development works.
6. Be tough during the interview
An interview is your chance to find out if they are way better than you ever believed ...or completely full of it, so do not downplay the opportunity to understand the team you will be joining. More and more studies and thoughts have been pointing to the reason why people leave -- the manager -- so ask real questions. Not “what will my day be like” but what will clearly impact your career and what interest you. This includes interviewing the members on the team, the CTO/CEO/CwhateverO. In another post, I’ll write out some of these.
7. Know when it's time to let go.
I sort of touched on this on the first point -- that technology you think is so cool, so awesome -- it'll go away. It'll become useless and obsolete ...or worse, only you will be able to handle it and you'll be stuck with it. As I’m going along in my career, I’ve noticed others can pick up a new language faster than me. I still want to sling code with them and build things, but I’m far more impactful as a mentor and coach, guiding others, teaching them all the mistakes I made. I’m still struggling with it and not in the weak sense. Even now as I write this, I know the team right over that wall is building something cool that I won't be part of. At some point, I’ll have to admit it completely and let it go. I feel like an old man with a damn good skill, I’m still good at it ...but is it time to let others take it and run?
Now onto the final chapter - part 4. Don't just work for someone because "it's a job"