As programmers, our sole job is not to code throughout the whole day. In this post, I document some of the other skills you need to be successful in your job as a developer apart from programming.
We also need to document our work, negotiate with our colleagues and managers about certain scope of work and particularly know how to refuse a task, especially one with a tough deadline.
Communication plays a major role in our day to day work (and life); even more nowadays with remote work and offshoring around the globe.
Let’s assume you’ve been assigned a task of transferring data from a CSV file for employees to a database using REST APIs. The system is already up and running.
You only need to create in the framework the company uses, a file or function that is going to take the file contents, check if valid and finally send through the service APIs. The architecture used consists micro services.
As a programmer, you don’t simply sit down and write codes. You also require the capacity of problem solving. Clear planning during this stage saves you plenty of headaches on the long run.
“First, solve the problem. Then, write the code.” John Johnson
There are plenty of problem solving strategies you can use in this scenario such as writing down a list of solutions like:
- reading the project and/or framework documentation
- probing the framework to see if this kind of solution already exists
- asking a colleague if he or she has already worked or stumbled upon such feature request
You then plan different options, sort by the easiest and start working. You don't simply starting writing the function straightaway.
Communication - verbal and writing
Once you go through the task, you see the documents for the API you’ve been given seems like a relic of the past, dated several years ago. You communicate with the project manager by initially sending an email. As the PM thinks the document is up to date, he calls you to discuss the situation. That’s where you need to be precise and accurate so as not to lose time.
Here are ways I improved my communication skills - both verbal and writing:
- reading a lot of books and articles
- reading books on writing such as On Writing Well and The Elements of Style
- writing often, such as this blog, linkedIn and medium
- participating in online communities such as Dev.to and Hashnode
- having the mindset of trying to improve this craft
The Project Manager with the customer’s deadline closing in thinks this task can be done in a couple of days at most. However, once you’ve gone through the docs and started coding, you realise that each row has multiple details rows, which makes data extraction far more complicated.
You now need to be able to negotiate how much time this job will take and also you will need half day off (to include) for some other work you have.
Some negotiation techniques I've been using for a win win situation:
- seek to listen and understand first
- not disagreeing at first by using phrases like "I think you are right", "I agree with you"
- ask questions about what you want or think is more realistic and give a reason such as, "do you think it's better to add an additional week because we have not considered anything going bad such as server downtime?"
I am currently working on to improve this skill as I still have plenty of improvement.
Saying no to someone can be the hardest thing to do, especially with a superior at work. But sometimes saying yes or agreeing from an objective point of view, can make more harm than good.
Consider for instance - that one of your previous tasks - has an urgent bug but you are already working on your EDI task.
As you are busy with an important work, you should be able to refuse and communicate the reason why. Additionally, if the bug is however more urgent, you can then stop this one to move one the other.
In one of my previous jobs, as I started packing up, my manager sent me an email requesting me to report on the task I did today. Before leaving the building, the only one in the team of twelve people (all working overtime), I walked across the table to explain him.
The next day he did a similar thing. As my time was almost up, he messaged me. This time, I did not read it and straight away closed my laptop lid and headed directly to the exit, without greeting anyone.
The manager tried this trick a few times with me but I did not play along. Other members of the team played to his tune though. I also tried talking to a few of the juniors but they were afraid.
I wonder where this type of education comes from. If they cannot stand for themselves, no one will. At this stage of their careers, they develop the habit of working too hard and not spending enough time with their families, solely for a few dimes more. But most importantly, because they cannot refuse instructions that are bad for them, particularly on the long term.