As a developer, Bill had the following 10 bad habits that restricted his performance and stunted his career growth. Make sure to avoid them if you are one:
- 1.Bill was a know-it-all
- 2.Bill did not take enough breaks
- 3.Bill stopped being a student
- 4.Bill refused to ask for help
- 5.Bill gave up too soon
- 6.Bill never learnt from his mistakes
- 7.Bill’s coding wasn’t very clean
- 8.Bill had a very poor Work/Life Balance
- 9.Bill did not plan his work before the start
- 10.Bill did not accept constructive criticism
- Share this:
- Like this:
1.Bill was a know-it-all
As brutal as it sounds, it’s true that you DON’T know it all. No one ever does.
Bill was a know-it-all. He was so convinced he knew all he had to know, that he did not realize that he had stopped learning. He downright refused alternatives or suggestions from his fellow developers. He looked down at them and as a result was hated by his team.
Being narrow-minded doesn’t help, especially when you’re a developer.
When there are things that you might not know – it is okay. It is also okay to disagree with someone’s ways of coding AFTER completely listening out. But don’t forget to give them a valid reason.
Be open-minded and accept that you don’t know it all!
2.Bill did not take enough breaks
Taking break links to lethargy, that is according to Bill. He never took breaks. A hard worker that he was, he refused to take time off. He would work constantly until his brain got too weary to even think. He did not realize he would never find a solution this way.
Breaks are necessary. When you’re stuck at a point, while coding, constant attempts will leave you frustrated and sometimes push you into depression.
Take breaks. Go for a walk, or spend time with family. Grab a cup of coffee, or listen to some calming music. Give your brain a break.
When you get back to work after your much-needed break, solutions come running to you!
3.Bill stopped being a student
Bill was so absorbed in working, that he stopped being a student. He was an experienced developer and spent all his time constantly churning only what he already knew.
He stopped going out of his way to learn new things. He did not realize that although he was an expert, his knowledge was strictly restricted to the times when he last learnt.
Coding is as vast as a sea. You can learn new stuff every day and still not know all that you need to.
Allocate an hour every day to quickly go through whatever’s new. Keep yourself updated. There’s no better way to grow than to learn!
4.Bill refused to ask for help
Asking for help was a sign of weakness, thought Bill. He refused to seek help because that made him feel insecure about his own qualifications. He was not willing to take a hit on his pride. He went through tutorials, he did his own research. But never did he reach out for help.
This might have been because
1) Bill once asked for help from a wrong group, who crushed his self-esteem.
2) Bill is pointlessly egoistic.
Take your time in identifying the right person, who’ll give you your answers. There are also forums like Stack Overflow, where most of the developers dwell, asking questions, posting answers. It’s a healthy habit, to ask questions.
5.Bill gave up too soon
There were projects that seemed to have crashed, no matter what. Bill would try fixing them, only to have another issue crop up. He felt frustrated at times like these when he was stuck, with no ways forward. Having tried multiple times, he would give up thinking he would rather do something more productive. All the time and efforts he put into that project would thus go waste.
The main culprit in such cases is frustration. It is natural to feel you’ve tried it all. But chances are, there are ways you haven’t yet thought of because your mind is constantly insisting on giving up.
Take a small break and think it through. Often more than not, the solution is just around the corner. Hold on for just a little bit longer.
6.Bill never learnt from his mistakes
When things went wrong, Bill’s entire focus was always on how to fix it. He would come up with solutions and get going, turning back not once. Bill did not take the learning his mistakes had to offer. Similar errors would occur, and Bill always spent time on fixing them.
When you make a mistake, slow down. Ask yourself what went wrong. Make note of the reason. Work out the possible solutions. Think of alternate solutions to the issue and the alternate issues that can make do with the same solutions.
When you keep a log of the errors from the past, the time taken to fix your future errors is a lot lesser because you have something to refer to. Learn from your mistakes.
7.Bill’s coding wasn’t very clean
The codes were near perfect but only Bill could understand. Sometimes, even he had to spend time to figure out what he had typed out. He inserted too many comments, to every code. The coding ended up looking shabby.
Write visually clean code.
Compromising on testing could lead to disasters at a later stage. They say “Better safe, than sorry!” for a reason. Testing is a MUST. What’s to lose, eh? Don’t ever compromise on testing.
8.Bill had a very poor Work/Life Balance
All Bill did was coding, every minute of the day. Bill believed that the time he put into coding was directly responsible for determining his success as a developer. He seldom took breaks and couldn’t help but neglect his family/life outside of work. This lead to overkill.
For some of you, coding is your hobby and it gets really bad because after long days or weeks, you will start to resent the fact that we will have to code. Even so much as starting to hate it at your job.
Don’t let it go to that irrevocable phase. Work on your work/life balance
9.Bill did not plan his work before the start
Bill never had a plan in place before he began working on a project. The result is well known – Confusion, chaos, errors and frustration.
The two most important resources as far as developers are concerned, are
Plan your work accordingly so you don’t have to rush at any point. It is always a plus when you have control over what you’re doing.
10.Bill did not accept constructive criticism
When you think you can never go wrong, it gets really difficult to accept criticism/feedback. Bill always took it personally when an alternative was suggested, or his work criticized. It affected him badly.
You needn’t take criticisms from all. But when those who are in the same field as you point out where you went wrong, retrace your steps and see if it makes sense. If it does, take their criticism positively, and work on it. It is called constructive criticism for a reason.
How can one grow if one doesn’t know where he’s going wrong?
Author Bio: Atman Rathod is the Co-founder at CMARIX TechnoLabs Pvt. Ltd., a leading web and mobile app development company with 13+ years of experience. He loves to write about technology, startups, entrepreneurship and business. His creative abilities, academic track record and leadership skills made him one of the key industry influencers as well.