Let me ask you a question — what are the most important traits of successful software developer? Experienced person would probably say “-It depends”. That’s true, all of this depends on our work and life experience. Back in time, when I was was on the beginning of my adventure with software development, I would say that successful people have to know everything, they are working in a “one man army” mode, and they can solve every single problem you’re putting in front of them. Damn… I wasn’t even close to the right answer.
It’s not about knowing all the things
Knowing all the things is one of the most popular myths about people which should be considered successful. During first days of my adventure with software development all those books, tutorials and guidelines were making me stressful. ‘It looks like successful developers eat all of that during their career’ — that was pretty obvious for me. Does it really mean that successful developers are experts in multiple programming languages, deeply understand all the patterns and practices, were participating in all kinds of projects, and have opinion about everything? For sure there are people who meet all these requirements, but is this a rule?
I don’t think so. I had a chance to work with companies of multiple kinds — startups, software houses, outsourcing companies— and none of those places was hiring a person like the one described above. Does it mean they were not interested in hiring an experts? Of course not! But their definition of expert was very different from a person who knows everything. So how does it look like?
Very often we’re calling someone “an expert” because they developed their skills in a “T-shaped” way. There’s one, very specific area of software development where such person is considered specialist, and there is a broad range of topics about which they know the most important, up-to-date facts. Instead of brand and logos of the most popular frameworks, people considered experts are thinking about common practices and solutions not dependent on specific programming language or technology. Such distribution of skills help them switch technological contexts very quickly, and think in more abstract way then less experienced colleagues. Speaking about colleagues, experts cannot ignore those with less experience — that’s why they’re able to discuss various topics with people from different departments, working on a completely different layers across the org. Experts definitely can into communication.
So what’s the rule here? Instead of knowing all the things, I would say that experts know one thing very well, while everything else stays in their area of interests.
As simple as that.
It’s not a single player game
If you think that software development is a single player game… well, you may need to rethink that. But okay — it’s pretty easy to find an origin of such belief.
It’s natural for us to explain unknown activities through parallels like movies about superheroes or soldiers on a battlefield. Very often Hollywood gives us this example of “xyz-man” possessing a superpower thanks to which world is being saved once again. We don’t really understand the mechanics of superhero’s powers, but we know that the villain will be defeated on the end of a movie. Some of us think that developers possess the same superpower thanks to which they’re able to solve problems of every kind on their own.
There are two main problems with such view. First, “external branding” of our job is full of false assumptions. Second, it can cause lots of internal issues for developers who feel they’re not good enough to handle problems like main characters of Hollywood blockbusters.
The truth is, experienced developers can easily say “I don’t know” without worrying that such statement could hurt their reputation.
I don’t know how to solve this problem, it’s the first time I see something like that. Can you look at it and try to help me?
I don’t know how to solve this problem, because that’s not the part of the system I’m familiar with. Could you help me understand it?
I don’t know if every corner case has been covered by my idea — could we try to solve and discover this incrementally?
Saying “I don’t know” and inviting other people to help you is often considered as one of the most important skills of successful software developers. That’s right — by saying that you need help you’re proving that there are more important things that your own ego — for example, successful delivery of this crucial project you’re currently involved into. Well-executed teamwork can reduce the time spent on fixing given issue, it may also help in distributing the knowledge more equally across the team, and this can result in saving meaningful amount of money for stakeholders.
We’re playing a multi-player game, and there’s nothing wrong with saying “I don’t know”.
Not everything is worth your attention
Two very common myths covered — successful developers don’t need to know all the things, and they’re not operating in a “one man army” mode. Third case is even more interesting — it’s about ignoring things which are not worth your attention. Sounds arrogant, isn’t it? Don’t worry — it really makes sense.
How is this possible that for some developers there’s always enough time to tick most of the items from their “todo lists”, and for others it’s undoable? For sure we can all agree, that so called “lack of time” is one of the most common issues of people around us, but is it really about lack of time? Aren’t we all equipped with the same 8-hour workday?
The solution for the “lack of time” problem is called “well-defined priorities”.
That’s it. Without the list of priorities, everything has the same importance. That’s the issue knowledge workers are struggling with constantly — I have some knowledge, I’m able to do various things, but what should I do next? Maybe I should do as many things as possible? Maybe I should answer every single e-mail because it helps me gaining the reputation in the company? Maybe I should work on every single ticket in our backlog without the need to set things in order based on our priorities? No, that’s not the way how experts operate.
Do you know the “Pareto principle”? It’s an observation saying that 80% of the outcome comes from 20% of the causes. For example, 80% of company’s profits come from 20% of its clients. 80% of sales is happening thanks to 20% of sales people. 80% of the most important issues is solved by 20% of employees, etc.
How to translate this rule for the context of programming? Well, think about it in this way — knowing the fact that we’re operating under time, budget and goals pressure, try to figure out this one thing which could push your project forward by 80%. Which core area of the application you’re working with could be improved bringing the most value for the users? Which task you could be tackling next is the most important one from the perspective of overall success of the project? Are there tasks which could be deferred, delegated to someone else or even abandoned?
Time is precious, so use it in the most effective way. That’s what successful developers do whenever they can.
Few years ago myths I mentioned here was taken for granted. It was obvious for me that I have to know the answer to every single question related to programming — otherwise people will treat me as a mediocre developer. The same thing with not knowing things, admitting that fact, or inviting other people to help me.
Was that a healthy point of view? Of course not. Is our environment really working in that way? Thankfully not! Thanks to growing experience I started noticing how far were my expectations from reality.
Sundar Pichai, Google CEO, once said that the velocity of development of IT industry, when comparing to our own pace of changes, makes him worried. It’s hard to say whether we will be able to develop ourselves at the same speed as GPUs, hardware and AI-related technologies, but definitely we should try to be as flexible as possible. Under market conditions changing so rapidly, our own values and beliefs should evolve over the time, and there’s nothing wrong about it. Some time ago we decided to work in an agile environments, so we cannot forget that agility is also related to ourselves.
Top comments (0)