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 … 

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.

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.

Career Advice: Stop Whining and Do Your Drill

"I feel stuck man. Not sure what potential I have at my current job. I just not happy here. People are great, but something is missing..." 

This is not the first I hear that, so I know exactly what to do. Usually I slap the guy, but this one looks like he could slap be back, so I smoothly move to the verbal part:

"Stop Whining and do your drill"

We, read as "software engineers", were trained to build products. Why your career is different? Do you know how to build a product? If yes, then you know how to build a career. Before I give you a recipe there is one catch. 

Career is not only climbing a corporate ladder. I have decided a long time ago that I want to work only on interesting stuff and made it a goal. Lately, I have noticed that I am good at building a new stuff, so I want to concentrate on that. One of my ex-co-workers decided that he wants to be happy and be home at 17:00. It can be anything really, not only "become a VP".

Now the plan:

1. Define where you want to be in 15-20 years. 
2. Divide it into 3 year chunks. 
3. Think how you get to the first milestone.
4. Get to work.

Oh, you don't know where you want to be in 15-20 years? Well, there is a different method then. Designed especially for guys that don't know what they want in a long-run: Agile Development. How does it look in Agile? Simple.

1. Define your goals for the coming 3 months. This should be easy as the goals are simple. They don't even have to be career/development goals. You can say: "I want to learn something new", "I want to feel that I've done something" or "I want to start some new project". It can be anything that you can somehow know whether it happened or not. I suggest to record your current state when you do that for comparison. You should also think about the goals and how to achieve them.
2. After 3 months check where you are. If you have achieved your goals, then return to step #1.
3. If after 6-9 months you are still unhappy, then you have to seriously re-evaluate your goals. There is something wrong with them or with how you achieve them. 
4. If after 9-12 months you are still unhappy despite all the above. Start looking for new options. It is not worth it. 
5. If after 2 years you are still unhappy and at the same place, come to me and I will slap you. 

Good Luck!

As a side note, the company I work for (EMC) has a quarterly goals system. It is mandatory, like in many other places. This system actually can be used for the agile method. It also will give you a feeling of purpose doing it.

5 most annoying things about changing expertise field

I've moved from storage to cyber security. Quite a move. Completely different field. I've been working in storage industry for about 12 years. Eyal has come to me saying "I'm doing this startup, join me". So, I've asked what it was about and he said Storage. This was 2000 and the startup was SANRAD. iSCSI was only beginning to happen and we were to ride its wave. Well, few years later iSCSI wave did not flip over FC boat, but I was working in storage ever since with a single exception.

I've been thinking bad things about security for a longer time. I basically, find it weird that people try to break other systems and other people defend those systems, when there are so many things yet to be done. We don't even have a good AI! No augmented reality! Damn, to play a video from your iPhone on SmartTV is not a simple task! So, the time being spend on fighting one another is seems like a such a huge waste. 

Apparently, it is a big business now. I've got an offer to start a product and a group from ground up. This is not an offer I can turn down. So, here I am, working on cyber security project. In the meanwhile, I've compiled a list of 5 most annoying thing when you change an expertise:

1. It feels weird not knowing stuff. Its like you are a fresh graduate all over again. I look around me and everybody looks much more experienced and knowledgeable than me (well, I have it all the time). It is weird instead of answering questions, ask them all the time about everything. Ask and translate even the simplest things: what is APT? Everybody talks about it, I have no idea what it it. It is exciting! This feeling was already worth the change!
2. Not knowing the field. I actually not talking about the "things" of the trade, like what is maleware, how it penetrates, what are the stages of attack, what is APT and etc. Those are easy to pick up. The problem is the Industry. What is the history and what are the hot trends. What are promising products and what products are doomed because the idea is dumb. I have a good feeling and strong opinions in storage industry, but I have no idea in cyber security. This is critical and a major obstacle actually, as we are trying to decide on the killer feature of the product and all I can add to discussion is more question marks.
3. Second thoughts. What if I've made a mistake of changing a field? Why didn't I stick to what I know the best? Why not make stay in the "expert mode"? There are pros and cons of course, and the main mean to relax is the thought that I can always get back. There are still doubts.
4. Phony experts. The real problem is not the phony experts, but rather that I can't tell the phony from real ones. Both sounds the same with the same acronyms, both talk with confidence, both have years of experience. However, one is talking nonsense while other is talking wisdom. Who is who? 
5. Crawling instead of flying. Learning is hard. I am actually waxed out after 5-6 hours of learning new stuff. I look at what I have achieved last week and it seems like nothing. I've learned a couple of things. Then I've found out that I've misunderstood one thing, so I had to re-learn it. In the same time, I am working very short hours, because I can't get any more new stuff in my brain. It is annoying! 

 Overall, it is really exciting :)  And I promise to write about it! 

What's in a title?

Senior, Principle, SDE II, Consultant and etc.
Many big companies have a technical career ladder usually with something like:

1. Junior Developer
2. Developer
3. Semi-Senior Developer
4. Senior Developer
5. Principle Developer
6. Senior Principle Developer
7. Partner Developer
8. ...
9. Distinguished Engineer 
10. Technical Fellow

Some companies, like Microsoft, get obsessed with those titles. In every major project you have to have a Principle Developer. Otherwise, how those simple Senior Developers could do anything?
You want to move to the next level? You have to prove that you are worthy. This gets into a many waste days hours discussing how this guys is a Senior and that guy is Principle, while this one is better.

EMC, my current employer, has a better attitude towards levels. It basically boils down to: "its not your business!"
In other words, nobody knows and pays much attention to the title/level. Why it is better? Because titles are basically like belts in martial arts.

The belt signifies that its owner trained for at least a certain amount of time and that he knows a specific moves. It does not mean that brown belt will always kick ass of green belt!
On average, this is probably true. In other words, if you take 100 green belts and 100 brown belts, pair them one with another, then most of the matches will be won by brown belts. It is still possible that the overall winner will be a green belt! Especially if this is previous boxing champ.

The point is that having a title does not make the person into a kick-ass developer. There might be lower-titled developers who are much more capable, but simply younger and didn't advance enough yet.