Math Career

A couple of weeks ago, everyone began to write about the upcoming Microsoft Development Conference PDC (Professional Developers Conference). In particular, Doug Reilly wrote the post “Who Manages Your Career?” . Many read and referred to the post, and some (for example, Sam Gentile or Robert Herlbath ) even developed the idea in response posts.

I will not argue about the cost of the PDC, but I agree with the idea that a person should manage his career himself. Often we try to focus on what we cannot change. But in fact, our career growth is in our hands.

I happened to collaborate with many developers. I noticed that the owners of outstanding careers know one secret: we must work on the first derivative.
')

Thought math would never come in handy?

Remember the beginning of the checkmate. analysis? Probably not. Maybe you stared at your classmates, or maybe you were a hangover freshman. In any case, somehow passed by the ears. But the first chapters of the textbook hinted at the secret of a successful career.

In the initial course mat. analysis, we were taught that the first derivative of the function is the rate of change of the function when the argument changes. In a career, time is an argument. The basic equation for a developer’s career is:

K = D + O * T

K is competence, that is, skills, knowledge and experience in software development. K measures employee value for the employer. It determines the success of a career. On the graph we will put K along the ordinate axis.

D is a gift, that is, innate abilities. For each person, D is a constant, but for different people, D is different.

O is learning, that is, the speed with which a person acquires (or loses) knowledge.

T is time. We will put off T on the abscissa.

From the equation it is clear that career success is determined by three variables. We can change only one:

• Obviously, T does not change. Time for all ruthlessly runs forward.
• D also not change. The truth is that there are more gifted people. Nothing can be done about it. However, D does not fully determine success. I was familiar with very gifted programmers whose careers did not work out. I also knew not very talented people who had very successful careers.
• But O can be changed. In fact, every day, consciously or not, we make decisions that affect O.

Work on the first derivative

From old habits difficult to get rid of. And often, instead of the first derivative, we try to change K itself.

• We are indignant if someone else has been promoted.
• We are indignant if it seems that the boss appreciates someone’s ideas more than ours.
• When searching for a job, we send out a document showing how high our K is .

We convince ourselves that the problem is that others simply do not notice how competent we are. Over time, we begin to believe that the opinion of others about our competence is more important than her own.

I believe that worrying about what others think about K is a waste of time. The key to a successful career is Oh , the first derivative. O is the speed with which K changes. Often the value of K at the moment only distracts. Only one thing is important: is competence increasing or decreasing day by day? Or does not change at all?


Is it obvious? Not really. Many people do not understand this, but those who understand are strongly pushing forward. For most developers, O is zero. Any positive o separates from the crowd.


If O becomes a positive number, then the career will go uphill for any value of D. The possibilities of one who becomes more competent grow every day.

Constantly study

For example, you can pay for the PDC yourself. This is an example of a positive Oh . You can go to the PDC and learn generics in C #, optimize queries to Yukon, managed APIs in Longhorn and much more. Over the last week of October K will increase.

However, PDC are satisfied every two years. How to keep O positive at the rest of the time? A successful career is not built if O only occasionally differs from zero. We must constantly learn.

It is necessary that learning becomes a process, not an event. Formal learning is not enough to keep O positive. It is necessary every day to come to work with the desire to learn something.

What can you learn in a regular work day? We spend 250 days in front of the monitor. How many days can you keep o positive?

Alas, these questions must be answered yourself. If you start looking at work from this point of view, then immediately there will be opportunities to learn something. What exactly is completely depends on you and your work.

However, something keeps us from growing Oh . We learn the most important lessons from our mistakes.

Learn from mistakes

In addition to formal training (for example, PDC), you can learn from mistakes. The value of O depends greatly on how we treat our mistakes.

My mistakes have greatly influenced my career. When SourceGear won the Inc 500 prize last fall, the editors asked me to say that I was surprised as an entrepreneur. I replied that I was most surprised that, despite the many stupid mistakes, I still ended up on the Inc 500 list.

I have led my company for seven years. During this time I made some great mistakes. Some mistakes were very shameful, so be it. I learned a lot.

Everyone sometimes does some crap, but not everyone learns from mistakes. Why? Often, a person does not learn from a mistake, because he wants to hide it.

You can find out most of all if you discuss your mistakes with a mentor or co-workers. Alas, this is contrary to the usual approach. When I messed up something, the last thing I want is for someone to find out how stupid I am. I'd like to hide the mistake so that no one would notice. Here we miss a great opportunity to increase our competence.

Sometimes we hide mistakes so well that we cannot even find them ourselves. What first comes to mind when the daily build breaks down? Someone else broke? People with a positive Oh most likely will immediately check if their chekin broke their build. The desire to learn implies that a person quickly understands his mistakes and can discuss them with others.

So there are only two options:
A) Manage your career.
B) Manage what others think of you.

If you choose A, then you can build an outstanding career. If you choose B, then career growth will stop.

Bug 5909

Not so long ago, we had the opportunity to practice this here at SourceGear. One of our best developers (let's call him Danil) made a really serious mistake. The error in the code itself was small, not very correct if, but the consequences of the bug were very serious.

Danil took full responsibility for himself. At first he fixed the bug itself. Then Danil began working directly with each client that the mistake made could affect. He was not afraid that his colleagues would be less respected. In fact, he coped so well with the situation that his understanding of C had improved, although that was not the goal.

As a result, our company has lost some time, but the main long-term effect of the 5909 bug is an increase in the competence of Danil.

Risks

I really want to say that learning every day is cheaper than going to the PDC :)

However, in fairness, it must be admitted that continuous learning has some risk. High About makes an employee vulnerable for the following important reasons:

• If an employee talks about his mistakes, the boss can punish them. The consequences can be very different. Maybe the boss will just consider the employee an idiot. Or maybe even fired.
• The boss may be afraid of the employee. Some bosses prefer subordinates with zero derivative. Consciously or not, they surround themselves with people who have stopped in their growth and do not pose a threat to the boss himself. If an employee working in such a team suddenly becomes a “developer with a non-zero derivative,” then he breaks a very delicate balance. The chief may react inadequately: the employee may be called a troublemaker, or even find a reason and dismiss.

These risks really exist, and the consequences are very unpleasant. Losing a job can be very inappropriate. This should not be forgotten, and I do not want to ignore these facts.

But why work for idiots? In either of these two situations, you need to look for another boss. So we came to the first law of management of the career:
Do not work for a boss who keeps you from learning all the time.

Consequence: the next time for an interview, pretend that everything is the opposite: it is not the boss who is trying to find out if you are worthy of work, but you are wasting your time to understand whether this person is worthy of being your boss.

PS

By the way, since you want to learn everything, then maybe you should try yourself not only in the area of ​​code and software architecture? If you work in a small NSC , or your responsibilities include managing people, then maybe it's time to learn something else? Once such a booze has gone, maybe to learn marketing ?

From the translator:
Many thanks to Youri_M4U for the link to the article and the idea of ​​translation .
This article was written by Eric Sink in his blog in August 2003. It seems to me that it is still very relevant.