Saturday, October 29, 2016

The Dread of Generalist


I am a generalist and I am scared. I have a new job working back to back with shamelessly good specialists. I am dreaded not to keep up.

For a long time I was wondering what is better: to be a specialist or generalist? On the one hand, specialist is the best in his narrow field. When you need a build, sorry, DevOps expert, you hire a specialist. You need to solve a Machine Learning problem, you hire a Machine Learning expert and not some all-around guy! In addition to having those jobs just for you, being a specialist might pay a lot. When a company is at need, it will pay obscene amounts of money for a specialist to do "this thing right now!" Just look at 2K bug madness. In case you are old enough to remember this stuff.

On the other hand, specialist is limited in career choices. Once you have invested all that time being Windows kernel expert, will you really move to be a PHP beginner programmer? I guess not.
Generalist on the other hand, can switch fields at will. I did that. I've ran Linux since 1996, then moved to work at Microsoft. I've worked in storage then moved to access and security, then returned to storage and now moved to security. Wait, what????

On the other hand, from the money point of view, generalist can (usually) grow to be a bigger manager than specialist. Again, usually and if she wants to. It is generally easier to see a bigger picture when you are a generalist, which is a good starting point for a manager. Actually, the truth is that the company will not easily give up on specialist to turn him into another run-of-the-mill manager. However, in either case, from the money perspective, being a manager pays off. 

Taking all of this into account, I decided to be both :) Since I am a generalist by nature, my plan was to work as a generalist till I get to a point where it is hard for me to find a new job. Then I will specialize in something. Most probably some kernel. There are not much of kernel specialists and they are always in need. In addition, it is relatively hard to become one. The best part is that everyone expects the kernel guy to be over 50, not communicative and not to fit in.

Well, the problem with my plan is the new places, like the one I'm in right now. Once I get to a new place, my impostor syndrome fears are multiplied by the generalist vs. specialists fears. Will I keep up? How could I ever match up with this guy that knows so much? Can she ever see me as her professional equal and come for advice?

Usually it works out just fine. I also have my methods and cheats. The best one is to be always right.
It is actually easier than it sounds. You just have to talk ONLY when you are 100% sure that you are right. In all other times: shut up.

Another cheat is to learn at night. This works especially good when there is a problem found towards the end of the day. A meeting is set for tomorrow morning and everybody goes home. Then you read about the issue and everything you can find for as many hours as you could. At the morning meeting you definitely sounds like a specialist (which is the goal).

I have a few more cheats in my sleeve, but I always wonder if this time I will be exposed. If this time, people will look at  me and say: "He does not know this! He is not as good as we thought he will!"

I know that it sounds preposterous, but I always fear that this time, it might happen … 

Tuesday, April 12, 2016

Work-Life Balance is a Scam

Your company cares about work-life balance? Maybe it is you who make sure that your life and work are balanced? Does work-life balance means "no emails on weekends", or maybe "no meetings after 17:00?" Is this: "leave your work problems at work be at home 100%?"

It sounds good. It is also a scam. There is no such thing as work-life balance. Work is a huge part of your adult life. Your working days mostly look like this (with varying hours and time slices):

DAY CHART

Granted you do get a work-free chunk of life before joining a work force and following retirement. However, most of your premium quality life, where you have money, health and independence, looks like the above picture. This is basically the reason the companies are saying: “We care about you very much and want you to have a fulfilling life. Do not spend all your time at work, so: No emails on weekends, no work on vacation, leave office at 18:00, etc.

Some of them are sincerely worry about you. They want to create a place where you are happy and will say to your friends: “This is a great place to work with a very good work-life balance!”

What is the problem then?

The problem is that it is the same as saying to somebody: “This crossfit thing is hard. You get tired and sweat a lot. We don’t want you to be hard on yourself. We suggest a laid-back crossfit! It is the same as regular crossfit, but really easy and you do not sweat.”  Well, this does not work! The whole point of crossfit it to be hard, so you can create a better version of yourself.

The same thing is with work-life balance. You do not get a refund on the time you spend at work! There is no scientific evidence or any major religion that once you die, you get to meet a clerk with a spreadsheet, who says: “You have worked really hard and had a very good work-life balance. We return you back for another 10 years! As a bonus, you will be 20 years old!” Not going to happen. Work is part of your life. How does “Life-Life Balance” sound?

I do not suggest to work all around the clock. There are things in life apart from work. Personally, I (very) rarely miss a dinner with my family. I get to games, events and holidays of my kids. Family is clearly a first priority in my life. However, I am blessed with a flexibility to work at almost any location and I use it. I work at any moment that I have time. If I can and it does not conflicts with anything else, I work at nights, weekends, vacations and sick days. Why should I spend my time watching endless TV series one after another, read rumors, watch “funny” videos, update Facebook or read talkbacks? I prefer to use my time for something worthwhile.

You do not consider your job being worthwhile for spending your free time on it? Well, you probably have another problem then…

As for me, it is my life and I am not going to spend it.

P.S.

I am thinking about starting a new branch of religion where disciples do get a refund on a work time. Join now! Get a refund!

Friday, January 22, 2016

Your Employee is leaving–When not to be happy

Креатив(80)

The answer is not: “Wait with the celebration until she leaves the building.” I assume here that you have actually wanted her to stay.

The answer is also not: “NEVER! I am always unhappy and always let them know that!” Employees leaving is part of the regular state of business. Lets be frank: do you plan to retire from your current company? All the 60+ guys please put your hand down. If you don’t plan to retire, do you only expect your employees not to quit the job before you leave?

Your employee is resigning. Should you ever be happy about it? Sure! Here are real examples from my experience:

  1. She is coming and explaining that her husband/son/mother is getting a job abroad/moving to/terminally ill abroad. In other words, she has to move to another country overseas. She is really bummed about it and she wants you to find a way for her to continue working remotely. Both of you consider it for a while, but then decide that it will not work out. You have to say good buy.
    As sad as it sounds you should be happy in this situation. True, you have just lost a great employee, BUT she wanted to make it work, she wanted to continue working for the company. She has left as your friend.
  2. There is this guy, who has come to your office saying that there is a startup company that offered him a dream job. He wants to stay here, but this is a one in a lifetime offer. He might even has come to you before asking for promotion, but there are no opportunities in the company yet. You talk about it and it does sound like a dream job, so you end up convincing him to take the offer. 
  3. There is this developer that wants to do something else. Not something that the company is doing. He wants to be a Web developer, but you run an embedded project. You have tried a couple of different projects, areas, modules, but nothing is working out. There is just no such thing as a web development in your company. You talk with the developer for months about it and in the end both of you decide that take different paths. Bummer? Sure! Did you depart like friends? Absolutely!

All those cases mean that you will have to hire another developer/QA/etc. You will train her, guide her and help her a lot. Until she will be an equal member of the team. Bummer? Yes. Should you be happy about the old employee leaving? YES! You should be happy!

Your job as a manager is to develop your people (well, this is one of your many jobs). Sometimes, you have to let them go to develop them further. In all those cases there is a common theme. You have been a part of the process. Moreover, you have build relationships with her. Good relationships that she would come and open up with her problem. She felt close enough to discuss a very sensitive issue with you. You had a decency to look for the best solution for her. Not for you. People notice that and appreciate that. You just earned a friend.

So, when you should not be happy when your employee is leaving?

When it surprises you!

This is the worst thing that can happen to you as a manager: your employee surprises you with resignation!!! Oh, they will have a good reason, they always do. Don’t believe them! Happy people don’t leave jobs they love! Especially, when the group/product is new. People don’t cheat on their honey moon. You did not see it coming? You should have! It is your fault as a manager!

It means that the employee was unhappy for a while, but you did not notice. She felt insecure or far enough not to mention it to you. Did you have a one-on-one meetings? Do you talk about personal stuff on those meetings? How do you make sure that nobody else is slipping between the cracks? Are others happy? You acn take it as granted: people don’t leave just because. They leave because they don’t like it here. If they like it here, they will go a long way to stay. Not the short walk to leave.

Surprised? You should not be happy…

Monday, January 04, 2016

Resolutions for 2016

I did not write resolutions for many years. I have stopped writing them as from celebration of yearly successes, they have become a depressing history of failures. Once I have noticed that I copy "learn enough French to understand a news site" for the fifth time, I understood that things are not working.

Why return to it? Few reasons:
  • Goals are important. Writing them down is even more important. 
  • I want to write more. Writing my resolutions will provide me at least 2 posts a year: resolutions and then excuses why I did not make them :)
  • I want to focus. Writing a few big goals will do just that.
  • Visualize progress. Years fly by. I am already almost 41. Writing goals and achieving them, exposes a progress in life.
So, what are my goals for this year.

  1. Do 2 fun days with each kid in separate. Those could be half days, if it will be enough.
  2. PhD:
    1. Publish 2 research paper
    2. Finish all the courses 
    3. Pass to stage 2
  3. Continue with leaning down and get to 80kg (or six-pack with a little more).
  4. Write 15 blog posts and 12 posts in LinkedIn. Blog posts should be different from the LinkedIn posts.
  5. Learn something new. Professionally.
  6. Sketch or draw - 8 pictures.
I have a bunch of other resolutions (be calmer with my kids) that cannot be measured. Thus, they are not on the list. Only those that are important for me and I can measure them made the list.

Well, good luck to me.

Wednesday, December 16, 2015

I am not here to make you happy



Many people think that as long as you are happy at work, all the rest will follow. The rest being interesting and engaging work, professional growth, tons of money, groupies, etc. They are wrong.

Those are the top 3 items from my manager cheat sheet:
  1. Ship a product.
  2. Build a group that can deliver. 
  3. Grow up my team members.

What is missing? The H-word. Yep, no happiness is involved. Working and delivering, being warm and cozy did not make the list.
If you are on my team, my job is to make you a better developer (here and below freely replace "developer" with QA, support, fill in your position). How do I do that? There are few simple ways.

First way is to assign challenging tasks. The goal is to stretch your abilities by being on a boundary of your abilities under assumption that this will extend your boundaries. Usually it involves doing stuff you've never done before. I especially like giving tasks that involve a completely unknown technology to the person. This is the usual exchange:

- (victim) I have to learn it first! It will take a few weeks!
- (me) We don't have weeks for learning. Take a week, learn enough to make some rough, first version. Then come back and lets talk on how to continue.

The developer then walks away calling me names (not in my face, usually). However, after a week, the first version is ready and it is better than everyone has expected. As a bonus,  I don't hear complains about the new technology anymore. It is not new anymore.

My other favorite way is vague requirements. Especially when they are coming from end-customer, but anything outside a comfort zone is great. Here, victims usually complain about other folks that were supposed to supply better requirements. They could be, product managers not doing their job, marketing and sales folks selling non-existing or impossible features, customers that do not know what they want. Once I've asked: "Do you want them to define everything?" However, after getting "yes" a couple of times, I have changed the pitch to "This is a great opportunity to understand a product from end-2-end perspective."
This method also begins with a developer being angry at me, other people and at the world in general. However, in the end it all works (with a little help). The results of this approach are less obvious and take longer than in the previous method. It take longer because there is no tutorial on how to deal with vague requirements. It takes time for the developers to understand a bigger picture, understand the customer, see the bigger picture and generally, have all the puzzle pieces to fall in place. However, once they do, the developers make better decisions that support business cases, they take more responsibilities, they move away from being code monkey.
Longer and less obvious, sometimes after my second glass of wine, I look back and say: "yeah, it all started there!"

Yet another method is to take risks. Most of developers are afraid of taking risks because they might loose. However, taking risk is also a win to big wins!
As opposite to assigning tasks, this method is usually more subtle as you cannot just say: "Take more risks." I usually lead by example in 3 simple steps.
  1. I say aloud that I am going to take a risk in a specific issue. I outline a strategy for risk taking, i.e. what are the risks, when and what are the checkpoints, if and when do we bail to a safe road. It is important to announce the risk taking ahead of the decision for two reasons. First, so everybody knows that risk taking was deliberate and not ad hoc. Second, it teaches planning in risk taking process.
  2. Execute on a risky path. This includes checking the progress, passing or failing the checkpoints, deciding on the future course of actions, etc.
  3. Retrospect and summarize. Face the decision and the outcome. See if you were right or wrong. Learn from it and continue. This is a very important step in saying "Its ok to take risks." Retrospect is critical especially when the risk didn't pay off.

Somewhat related to the risk taking is being wrong method. Young folks want to earn appreciation and think that not being wrong will get them there. Senior developers are afraid to be wrong because they think they are supposed to know everything. Well, both of them are already wrong:)
It is ok to be wrong. It is ok not to know things. If I do not know something, I can learn it. However, if I afraid to admit it, I will never learn it. I used to look for "I don't know" in a hiring process. A person that can admit her boundaries, usually is humble enough on one hand and confident enough to admit it on the other hand. Those people are joy to work with.
So, how to teach this attitude? I do it in two ways. First, I use myself as an example. Luckily, there are plenty of things I'm wrong about or things that I don't know, so I talk about them. I expose my flaws in public without excuses to show that it is fine. Second, I drill with questions until getting to "I don't know" or to "My mistake." Then I immediately say that this is ok and act to give the developer a feeling that this is indeed ok. Thins (supposedly) trains the developer in being wrong and making himself right. 

Extended ownership method. Give a developer more responsibility than she usually gets (or wants). Then add some more. Let her take the calls in decision points (with my backup of course), let her present the project, talk with other groups, oversee testing and documentation, etc. This method is the best, because it also means less work for me in the long run :) The catch here is to set the developer for success by providing a safety net that is safe enough for the developer not to fall and on the other hand, it should not be too tight to allow the feeling of ownership. This is a hard thing to do and sometimes I screw up in that. The good things is that I admit my mistakes and try to fix them the next time. 
Once a developer owns the project, it is all worth it. You can actually see her becoming a better developer.

Those are the 5 major methods I use to grow my team members whether they want them or not. The common theme for all of them is that none of them is easy for the developer. None of them makes the developers happy in the process. It is ok. I am not here to make you happy. I am here to make you better. I do aim to make you Eventually Happy. Which means that I do hope that some time in the future, you will look back and say that this was the period that you've learnt a lot and was worthwhile all the challenges.

Saturday, September 26, 2015

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.

Friday, September 11, 2015

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.