Getting Older or Getting Better?

I've crossed 40 lately. In hi-tech I am officially old. Not really old yet, this is reserved for 45-55 guys. Nobody talks about *those* guys. They can really see the retirement around the corner.

As I am getting older, there are more and more conversations with my colleagues about staying relevant and how hard it is to find a next gig. Apparently, they are getting older as well and worried about the age. 

I am not worried about find a job. I have a secret that keeps me in a loop. 

I am a batman. Wait, this is my other secret...

My secret is that I practice. 

Why people are afraid that it will be hard to find a job at 40-50+? 

Because they are afraid that 20-30+ folks can be hired instead of them at lower price to do the same job. They are right. 

Why should anyone hire super senior developer, when he can get the same level developer paying half as much? 

Job market behaves like any other market, i.e. it is driven by supply and demand. If demand it higher than supply then the job is in ``shortage''. If demand is lower than supply then the job is in ``surplus''. Clearly, it is easier to find a job if your skills are ``shortage'' skills, i.e. you can fit ``shortage'' jobs. Interestingly enough, this is correct for any level in a given skill.

It is tempting to say that good kernel hacker will find a job much faster than the average kernel hacker. This is not really a case. Good kernel hacker will not turn to jobs that average hacker will be happy with. This is true both in the quality of tasks she will get and in money she will earn. Those hackers basically do not compete for the same jobs and thus, good kernel hacker might be in surplus market while average might be in shortage market.

If you are 40+ old, the last thing you want to do is to compete with all the young folks for the same job. Maybe not the last, the last thing will be to wrestle with a bear, but second last. This means no PHP or Angular for you. Unless, you are writing those things. You cannot just be an Angular programmer, you have to be Angular expert. The one the young developers are coming to ask really hard questions and who's presentations they are watching to learn Angular. You should either be the first one running with the thing, this means investing your time into getting better and also putting some of your stuff out there, or you should go deep. Really deep. This again, requires investing your time into getting intimately familiar with Angular (or anything else you pick). 

Another possible way is to pick some niche or a field and invest a lot of time in it. I was picked by Storage somewhere around 2000. Since then I've worked in a few companies on a different things, I have read storage news, listened to storage startup speeches, watched videos, read books and blogs. Only about 1% of all this information stays in my brain, but over 15 years this is enough. In storage, I have a handicap over younger folks, which is a net gain for storage companies and for me. Teenagers are still way cooler and looking better, so I will not get all jobs. 

There are plenty of niches out there. For example, I have interviewed a lot of a young developers and most of them do not know C/C++. Come to think of it, almost nobody knows C++. Almost no young developer understands kernel development. Especially Windows kernel development. Interestingly enough, most of the kernel "experts" do not understand it either. Build and deployment areas are currently undergoing a major revolution with DevOps and automatic tools. Most of the developers never heard about it. Distributed systems are still hard for humans, even with the abundance of messaging queues and service buses. Clustering is a high-promise concept for 20 years and it is still hard. Any software that is close to HW is good. Anything that requires holistic view is great. There are plenty of others, just choose.

So, pick something and get better in it. Don't just "work with it", but get better. Read, learn, improve and repeat. Do not experience the same year over and over again. If you actively improve yourself, the equation flips over. Now the time is not your enemy, it is your friend. Well, not friend as "lets have a beer together after work", but the time is working for you. All of the sudden, you are not just old, you are experienced. Moreover, the older you are, the more experienced you become.

Making graphs for your scientific paper

I am writing a paper that compares a couple of algorithms. My prof told me to write a simulation and to make some graphs. As this is not the first time I am doing that, I wanted to describe the process. The first was painful. This time I almost enjoyed it.

The first time went like this. 

1. Implement a simulation. There is a main class that drives the simulation and then there are specific algorithms. So, the main class calls each algorithm and the algorithm prints out the results.
2. Redirect the results into a file. 
3. Open the file in your editor of choice, which is clearly VIM. Manually combine columns into a single file that gnuplot can understand.
4. Open gnuplot and draw a graph. Save the graph in PNG and embed in a paper.

Now, I send the paper to my supervisor and gets a lot of rejects. Dataset should be larger, samples should be smaller, parameters should be different, etc. So, it is back to the same 4 easy steps.Rinse and repeat. And repeat, and repeat...

The process should be automatic. This is how I did it this time.

Gnuplot should get data files that have columns. 




 

To eliminate step #3, this file should be output by simulation directly. The problem is that each column is generated by a different algorithm, which are called sequentially by the code. The way to do that is counter intuitive in a way, the results have to be gathered by the main class, which will then output them all together. 

 This is a code snippet. Gathering of results are highlighted in yellow. Notice that not only results are gathered but also the titles of the columns are fed from the specific algorithms to the main. This is absolutely required, as each line in gnuplot should be labeled and I don't want to add those labels afterwards.

The next step is to automate graph generation. This is done by outputting a gnuplot script (outlined in blue). So, now simulation runs, outputs data into file of all algorithms, outputs gnuplot script. Gnuplot then generates graph automatically.

The best part is that the code generates two graphs in a single run (two calls to "OutputGnuplot"). I can easily generate another one, as all the data is in one place.

As I said. Almost enjoyed it.