Where do you see yourself in five years?

This must be the most annoying question for many people during an interview process. An interview is a stressful situation, even for the most experienced performer, and yet you’re asked to predict the future, your future, just like that, without any other factors in. To be honest, I do not know what HR people want or think when they ask this, and I’m not sure they also do; I bet most are asking it because it is in their checklist.

Parenthesis on prediction: Five years is a long time. Often I am asked by friends and acquaintances on the (business) value of certain Engineering studies. I have learned to not answer this question, because it carries a lot of my biases, but also because I tell them this: If someone told you in 2007 that they began studying Civil Engineering in Greece, you’d assume -and tell them- that if they like the field, they won’t be out of work. Now Civil Engineering is 5 years of study (add one more for an MSc, a normal tradition in Greece) and you’re now in 2013, right in the middle of the Greek economic crisis, competing with thousands of other Civil Engineers, both old and new for virtually no work offered and for pennies.

That is why I hate these questions. But I’ve learned why certain people ask them. And this may provide a guideline how to think about these without hating the question or the interviewer. I am copying the relevant parts from an interview Brian Krzanich gave a few years ago:

I give the same advice to women and men about that. I tell them that there are three mistakes that people make in their careers, and that those three mistakes limit their potential growth.

The first mistake is not having a five-year plan. I meet so many people who say: I just want to contribute. But that doesn’t necessarily drive you to where you want to go in your career. You have to know: Where do you want to be? What do you want to accomplish? Who do you want to be in five years?

The second mistake is not telling somebody. If you don’t go talk to your boss, if you don’t go talk to your mentors, if you don’t go talk to people who can influence where you want to be, then they don’t know. And they’re not mind readers.

The third thing is you have to have a mentor. You have to have someone who’s watching out, helping you navigate the decision-making processes, how things get done, how you’re perceived from a third-party view.

After that you can now have a discussion. When you want a raise you’re not only going in saying: I want more money. You’re going in and saying: Here’s what I want out of my career. Here’s what I accomplished. Here’s what I said I was going to do. Here’s what I’ve done. Not only do I deserve more money but I want to get to here on my career.

Because what you really want is to build a career, not just get the raise. And if you do those things, whether you’re a man or a woman, you’ll be a lot better off.

If you’d asked me in 2013 where would I see myself in 5 years, there is no way I would have predicted that I would have worked for three startups, a brief stint at Intel and the software house of the biggest lottery on the planet. I was working in the Public Sector and doing relatively OK. But I know I needed two things: A pay raise and to sharpen my skills. And mind you, I was not telling anybody nor had a mentor. I did not even know how to interview. You do not have to wait to have coffee with someone to get your push like I did.

Plan ahead.

Confessions of a Necromancer

Confessions of a NecromancerConfessions of a Necromancer by Pieter Hintjens

I knew of Hintjens’s work (Xitami, ZeroMQ, etc) but not much more of him. The book popped up in a Slack I am a member of while discussing Torvalds’s decision to take a step back and work on himself.

Hintjens writes a technical memoir. At least that is the first part of the book. And because he writes stuff about the era of computing I grew up into, I like it. He reminded me of technologies, tricks and methods I had long forgotten. I even learned new old stuff that I had never come across.

And the there is the second part of the book. The most important and most interesting one. What can I say about it? Not much I am afraid. I can only declare my respect for his effort to document the process and his voyage towards the end. I envy his clarity, even though I cannot even begin to imagine the cost for it to be maintained during the cancer treatment process.

Highly touching.

View all my reviews

PS: I am trying to see whether using Goodreads to write my thoughts on books I read is a thing that I like.

Parsing Techniques – A Practical Guide

Memory gets triggered in the most unexpected ways. I maintain a fairly large library of printed and electronic books (most of them DRMed -the light cases socially, kindle and Adobe locked the rest unfortunately) on subjects that interest me. It is fairly evident that I will not read them all, but I always have a book (and sometimes a paper) to recommend to a friend that has a problem. It seems that I am not the only one that thinks that personal libraries are supposed to be full of unread books.

Anyway, I was listening to Podcast.__init__ Episode 95 and one of the guests mentioned Parsing Techniques – A Practical Guide by Grune, I think it was when they touched Earley parsers and how most books about parsing do not really touch on how the actual parser is built. Wait a minute I’ve got that PDF! And you can go to the author’s site and download it. And you know what? There is a second edition out. For > 100 euros for a DRMed PDF I may not buy it since parsing is definitely not my thing, but somebody else out there might need the second edition. Judging from my skimming of the first edition, this is close to the encyclopaedia of parsing. I will go through some pages tonight.

Just for a refresher.

The Soul of a New Machine

That’s the bear trap, the greatest vice. Your job. You can justify about any behavior with it. Maybe that’s why you do it, so you don’t have to deal with all those other problems.

I never expected to find the explanation of BOFHiness in The Soul of New Machine. The book lived on my wishlist for a long time and it was gifted to me, only to wait there inside the kindle for a couple more years. Tracy Kidder follows the team that built Data General’s Eagle, their first 32bit machine and a kind of Plan B for the company, since the market was being dominated by the Vaxen and they had to react. Serious computing history unfolds in front of you.

A very interesting story, and lucky Kidder got to follow a lot of the story in the making, even though this was supposed to be a secret project. While this is not a hard science book, you get to learn a lot about computer architecture, or depending your skills, computer architecture history. You get to understand the magic that happens when your keystrokes are transformed into the desired result. The moment when the software and hardware connect. I particularly enjoyed the chapters about debugging boards with an oscillator.

While I cannot claim the brilliance of Tom West, I do see elements of similar behavior and the reasons for this. I need to work on that.

Thus he supplied them one answer to the question of what happens to computer engineers who pass forty.

I reached 44 yesterday. Still not a middle manager.

serverless and the last engineer

I make it no secret that one of the most impactful essays on me the last 20 years has been Bob Lucky‘s essay about the last electrical engineer. And I have seen other computer scientists taking it into account too.

Ever since cloud computing caught on, it comes more and more frequently to mind, because I see that the abundance of computing power makes people think that they can get away without really thinking about the problem. After all, computing has become cheap, right? The prototype you’ve just rigged up costs $10 / month to host. Well scale on the other hand does not come cheap and it will bite you.

Now that “cloud” has become a commodity word, “serverless” is coming to dominate. Because you really do not need to buy your infrastructure since, you know, you can have a data center as a tab in your browser for half the cost. And you really now do not need old-school sysadmins, since you make people all work together and deploy stuff n-times a day (DevOps).  But hey, even that is complex, because you just want to write the damn stuff and not think on where it runs, or how the hell it is supposed to run on scale. You only want profit on scale.

So let’s go serverless. And in the process, let’s make the prophecy about the world needing 5 computers true. Only they are cloud / serverless providers (just count the big players) where for some engineers, paraphrasing a bit Bob Lucky, life will be:

Projecting the current trends, future applications will be serverless.  No one will have the foggiest idea what is on that cloud.  Somewhere in the basement of the serverless provider or its successor will be a huge computer file with the listing of that infrastructure.  The last engineer will sit beside the file, handcuffed to the disk drive like a scene out of “Ben Hur.”  That engineer will be extremely well paid, and his or her every demand will be immediately satisfied.  That engineer will be the last keeper of the secret of the universe: E = IR.

Bootcamps and other vocational training institutions will turn out lots of serverless programmers, so prepare at least to be able to tick the Steinmetz chalk mark.

You are a writer (so start acting like one)

I got You are a writer by Jeff Goins on a day it was given for free years ago. I got to read it over the weekend. I thought then, and I still do no now, that the book offers advice to people who write code too. Maybe because sometimes I believe that code is like a poem. So I will try to rehash advice I found useful here, since this seems to be one of the acceptable self-help books that have come my way.

While anyone can connect with anyone and put stuff out there, how does one gets noticed? By helping people. By relieving their pain. I’ve advocated answering one question per day on ServerFault (or StackOverflow, or whatever clicks to you), although I do not always practice this. I used to, though, years ago when mailing lists and newsgroups were the thing.

You need to build a platform. This blog is a platform. I post stuff here. Others do it with more success, for example John Sonmez who uses a variety of platforms (blog, YouTube channel, podcast, book) to publish his work (and he gives 90% of his work for free he said on Ruby Rogues). You make the platform and you establish a brand. Without a brand you are forgettable.

And you know what helps you not being forgotten? Networking does. Meaningful relationships do. Relationships that are mutual, matter to both parties and give you the opportunity to make friends and find mentors.

But nothing of the above makes any sense unless you are prepared to answer the following questions:

  • Am I serious?
  • Am I committed?
  • Am I prepared to be challenged?

Please take the time to sincerely answer these questions. And while you are at it, understand that you probably are not the best coder in the world yet. But you can become one. There is room at the top here.

Like one of the main characters in The Phoenix Project said, mastery comes through practice. And here Goins argues that the best kind of practice is done publicly. Interestingly GiHub seems to be our public place of practice.

While you’re at it, learn to estimate. Underpromise and overdeliver. Especially when you are part of a team. Like Goins writes, you have a gift. Someone is willing to work with you.

Go on! Practice.

Start me Up!

I cannot even remember how many disks Windows 95 was, fourteen, fifteen? Something like that. And how many hours installing it to machines around the lab.

That was the day I said goodbye to FTP software’s PC/TCP and Trumpet Winsock.