How to be an Effective Individual Contributor in Software Engineering
Individual contributor (IC) is a role in industry for a person who contributes individually and does not manage other person. This type of individual is hired by skills and willing to dig deep on those skills, not the ability or willingness to manage people.
In software, this position is identified usually by the title minus these words: manager. For example Software Engineer, Senior Software Engineer, Principal Engineer, Distinguished Engineer, Quality Analyst (QA), Senior QA, etc. This position: Engineering Manager, Director of Engineering, VP Engineering is a managerial position not considered and individual contributor.
This writing is about something I learned, sometimes the hard way, about how to be more effective as an individual contributor.
Starts by asking why
As an individual contributor we’re given problems we tend to get excited and try to delve quickly into those, analyzing, building solutions, build prove of concepts. I actually was in this kind of situation before and excitingly throw myself into working. When the solution is finished, it turns out it’s not delivering much value and solving the real problem.
The junior me always ask “How can I build these?” “How can I solve this fast?”. But miss the most important thing: “asking why”.
By asking why, we can search for any existing alternatives, or even propose an alternative before we build our own implementations.
By asking why, we will make sure that what we’re going to do has a significant value or just a nice to have.
By asking why, we would save tons of time working on something not important enough and save ourself by working on more important one.
By asking why, we will better prioritise our tasks at hand on which one will be more delivering on values than the others.
Is this make sense?
The ex-Minister of Transportation of Indonesia and ex CEO of Indonesian Railway Company, Mr. Igansius Jonan, once said in a Studium Generale at ITB, about the importance to have a reasoned mind. At the time, he is tasked to transform Indonesian Railways Company that is in a very poor state. It has so many problems, including corrupt bureaucrats, poor train conditions, inhumane conditions of commuter line, and many more.
One time, he is confused why in a long distance train has no proper toilets. Imagine at that time all toilets is flushed directly to the rails, no proper waste tanks available. He decided to make a proper one, he called the folks who run the RnD for the company and ask the estimates about how much money to build a single unit of toilets.
Surprise-suprise it costs x Billion Rupiah! He said, what the heck? It doesn’t make any sense at all. How come to make a single unit of proper toilet cost so much, it’s not even a luxury car, it’s just a toilet. (During this era, the practice of markup is considered normal). Then he asked again and again to re-estimate, re-designed etc, and the price dropped to just some millions of rupiah. And even, he patented the toilet design.
He also told another case in Lampung, there’s a railway that send cargo and coal between Lampung and Palembang. The rails always have the same issue each year: the thickness of the rail steel is always declining. The weird thing about this issue is the traffic of train is far less busy than those in Java. So why is this happening? Some “experts” from top universities have been invited to conduct studies about it and find solution, but nothing come out of it.
He personally went to the site and check it. Then… solved it. The “experts” said what “study” do you use? “No, he said”. “I use only common sense”. He saw that most of the train carts are cargo containing goods and coals from local mine. Most of them are overweight and the officials never conduct any weight check on this. So he instructed immediately to have those carts check. regularly, and forbid any overweight train. Since, the carts are regularly checked for overweight, the problems disappear.
So, the key takeaway is, use your common sense first, before you go into implementation details, it will save a lot of time and money.
Basic knowledge is your friend
Time and time again when I get stuck on some hard problems, the solution for it starts by something fundamental, either basic computer science, basic programming language feature, quickstart from a framework, hello-world program, and so on. Many programmers wants to build something fancy, but they neglect fundamentals and straight jumping to the advanced things.
Most of the results are okay, until they found bugs, then they’re stuck, do some googling, some are lucky to found similar problems, but some are stuck because they case is unique.
To solve it usually comes to 3 ways:
- Trace the flow of data using a debugger or printing to stdout
- Eliminate all possibilities of the root cause, this is a trial and error approach.
- Back to basic, rethink the design of the program and build a stable one.
In my experience, step 1 and 2 will fix the problem as a temporary solution, but step 3 will make sure that the bug is gone and produce more stable program. Stable program doesn’t mean bug free, it means if you encounter a new bug, it will be easier to spot the root cause and it will be easy to add a fix. Of course it will be easier to add or remove a feature too.
To be good at step 3, learning in depth about basic computer science and data structures, computational thinking, programming paradigm, clean code, design patterns will be a great asset and make a huge differentiation.
What will you do if you were not afraid?
Most of the times what drag us down is fear. Many creative ideas just flush down the toilet because of fear.
Because of fear we hide ourselves, not tell anyone about them and to be proactive.
The answer will always be NO if we don’t ask for it.
Ignore the naysayers.
Do it, there are only 2 outcomes: win or learn. Sometimes we win, sometimes we learn.
The naysayers are mostly fail or keep being average by staying still wherever they are.
But remember, don’t be reckless too, your common sense should be your best friend.
On Communication
Intuition Driven vs Data Driven
This is a two-sided coin. Some people can do well with just a glimpse of evidence and vision in their mind. But some people can only see it if they see real proof or data.
Some persons tends to think by concepts, design, abstract thinking.
And some people can only see by proof, facts, and real data.
In MBTI the people with intuition driven is classified of type N like INtuition, data driven people is classified as S, Sensing.
Point to be remembered is, not all people have the same trait, try to know this and act accordingly.
Show data / real evidence / code in Argument
Talk is cheap. Show me the code — Linus Torvalds
You have arguments all the time, the only thing that will back your argument is real data. Good reasoning backed with data will always win.
If you’re silenced without any reasonable explanation, then you probably work for criminals :)
Never take it personally on professional relationship
Sometimes we got arguments at work, we can also need to have some rough edge in discussion sometimes a heated one. As long as it’s not one person hurting another one verbally or physically, it’s okay.
Be Constructive
To grow, people need constructive feedback from peers and mentors.
Feedback is different than criticism. Criticism doesn’t have any solution to any shortcomings.
But most people don’t like to be told that they lack something, it’s best to give them understanding that the feedback is not meant to be some kind of personal attack, but to the result of work or attitude for the better.
Feedback should be done in private, 1 on 1 meeting, or a direct messages, or closed loop like in code reviews.
Be Kind
Basically, people are decent, sometimes situation and bad experience makes people to be bad. Seek to understand their situation, and act accordingly.
On Work and Learning
Show Progress, not Perfection
Keep shipping, don’t ship shit — Anonymous
This mantra always be my mantra since the day I know real world programming.
Show progress by keep shipping, gain TRUST by NEVER ship shit!
What’s the definition of our best work? It means if your software is considered “good enough”, means it does its job, should be readable, have tests, handles error well, have meaningful logs, follow security best practice, and have clear documentation.
The power of focus
Keep your tasks at the minimum for one day. Commit on finishing those tasks, this will make you easily show progress daily.
Swift decision is better than no decision
It doesn’t mean to do things recklessly, it means quick thinking of the situation. If decision is not made quick enough you will not make any progress or blocking others’ work.
Make a timebox, propose a time to do research of problems you don’t know the answer yet. When the time comes, make up your mind to choose. If you’re wrong in the end, it’s okay it means you learn something and you will not fall to the same hole twice.
We can not master everything, collaborate and ask for help!
Regardless of how good you are you can not master everything, so if you’re stuck ask for help from someone, ask for feedback.
Seek Mentor
Find a good mentor. If you can’t find one, you can watch or read their personal interview, or pick some successful people’s book you like, or see their code on Github. Learn from them, especially about their habit and their recipe to success, and try to do their habit and tricks.
Keep on learning, but don’t fall for hype
Keep on learning and open our mind. New technologies will come or you might create it! But don’t fall for hype. Because of some new shiny database is invented and we’re migrating to it immediately. Don’t also maintain status quo for long. We need to adjust our tech according to our needs and according how mature the tech is.
When we were building YesBoss, we thought that NoSQL is the new cool things, and we implemented all our systems using MongoDB as main storage database. Only to know later that MongoDB (before 4.0) was still not ACID compliant. We were forced to manually build our lock mechanism for this, and of course it’s not the best solution. We eventually moved to MySQL and until know it’s still serving our production system well enough.
My take on this when you found a new tech, unless it’s production ready and cater our needs, never use it for business critical systems.
7 Habits
It’s important to learn this first step to sucess.
Read it or watch the summary.
Conclusion
It’s all about gaining TRUST
So what’s the big deal with those points above, why I really need to take your suggestion?
It’s about gaining TRUST. If you’re a trusted person, you’re not gonna worry about not having a job. When people think about specific things that you can do, you will be the first on their mind, you’re not gonna be pre-checked, or going on trial or probation, people will choose you instantly. Because they trust you and on their mind you’re a reliable person they can count on.
Books I Recommend
- The Effective Engineer, Edmond Lau
- Clean Code, Uncle Bob C. Martin.
- Domain Driven Design, Eric Evans
- Code Complete 2nd Ed, Steve McConnell
- Design Patterns, Gang of Four
- 7 Habits of Highly Effective People, Stephen R. Covey
