Why your developer sucks

1. He/She has a ‘God’ Complex

Web Development by its very nature is a creative field. It’s a field were the developer invests themselves. The Developer looks at a problem and solves it the best way they know how. If anybody dares question how the problem was solved, it is considered as a personal attack on the developer skills. I see this in myself every day. When somebody fails at completing a task with the software, the natural response for a developer is “god you are the most retarded person I know”. But of cause this is not true. Donald Norman in his Book “The Design Of Everyday things” says “If an error is possible, somebody will find a way to make it” (Not a word for word quote, Great book by the way). And itโ€™s not because they are stupid, it’s because your application allows for that error/failure to occur. Design for errors. Developers should never test their own software.

2. He/She worships his/her Code

This one is closely tied to the number one above. Your developer loves his/her code, therefore it is the best code it can be, it will never need re-factoring, if anybody writes it different they are stupid. This sort of attachment leads to low quality work and developers that don’t grow. Be wary of developers that think they write the best code in the world.

3. 70% coding, 30% planning

Most developers get a problem and the first thing they do is start coding. Adding and removing stuff as they go along. Creating new functions as they go along. But the truth is if they took more time in planning, their development time is decreased dramatically. And the quality and structure of their work is improved. So aim for a 70% planning, 30% coding. **This is just my personal opinion.

4. Bad time estimates

Your developer will usually go over their time estimates; the trick is never believe a developer’s time estimate :D, cause we lie. And we donโ€™t lie to you, we lie to ourselves. And we believe it. The lie to you is just a by-product. We over estimate our skills and we live in a purple fluffy world with Smurfs and Teletubbies where everything goes according to plan and there are not unexpected errors or events. Giving time estimates is a skill on its own and a developer does not have that skill as i had to learn it might make them unhappy with their job. Again planning goes a long way. Also be wary of the ‘project managers from hell’ pressurising your developers unnecessarily to score some points with you.

5. No desire to learn new things

A developer should always be growing, improving, finding new/better ways of doing the same stuff he’s been doing for years. And there is nothing worse than a developer who cannot learn new things by themselves. Team work is fine and all, but a developer that cannot learn by themselves is going to cost you time and money and frustrate your development team. I happen to think when it comes to learning a new system, discovering things on your own is the best way to learn, breaking things and fixing them and finding out why they broke, etc. I have my own little list on What a Web Developer should know.

6. You give him unclear instructions

Never tell a web developer “Go build me a rocket please”, you will get a flying saucer. Be specific with what you want. It is best to get a trained business analyst if you cannot do this yourself, someone who will understand the requirements of the users and the desired behaviour and outcomes of the system. So yes your developer sucks because you think you speak ‘developer’ but are you are just human…or are you dancer ๐Ÿ˜€

7. Being a perfectionist(Thanks James)

I had missed this one but thanks to @jamiebarow for pointing this out. “I am a perfectionist”, Yes it was cute he/she said it in his/her interview. Its great to have great attention to detail, but too much attention to details can cripple a project. Some developers write and re-factor at the same time(I feel an infinite loop coming on). Which sorta takes us back to number 2 above. Code worshipping is blasphemy.

8. He/She has no idea WTF he/she’s doing

Sometimes you just get stuck with a developer that has no idea what they are doing, just good old fashioned ‘stupid’ for lack of a better word. Iโ€™m kidding nobody is stupid, but some developers should have been mechanics. Just saying. :P. James says not knowing is fine as long you are willing to learn. True story.

9. Conclusion

Although this sounds like itโ€™s meant for your boss, Its really meant for you. Stop sucking at your job. Be approachable, be sincere, be wrong, be willing to help others get better. Understand you are not perfect and quite possibly might suck. As long as you are willing to learn and driven. Iโ€™m still working on some of these things myself. Will keep you posted. I wrote another article on How to become a web developer. Take a look and let me know. Enjoy.

Adios
Tali

  • Share post

A collection of particles named Tali Luvhengo

16 comments

  • I’d add another thing: being perfectionists. I think a lot of coders like their code to be perfect. But as some people say “Write dumb code”, because if it’s easy to read, it’s easy to maintain. Some smart one-line of code isn’t better than a stupid 5 liner… usually… because of this. The time spent on trying to make something perfect can be a waste, especially if it’s on functionality that doesn’t end up being shipped in the end. Or if it gets completely re-designed at some later stage. I guess this also re-iterates the importance of planning up-front.

    Planning is definitely something I need to improve, and time tracking. They’re related – being able to decide on what tasks need to be done, and tracking them, is hard! Especially deciding what granularity to split them up into.

    Nice post!

    Just two things:

    1. the numbering of the points is wrong (two 5 and 6’s) ๐Ÿ™‚
    2. not knowing WTF you’re doing is fine as long as you want to learn, and take it from not knowing to knowing

  • Thanks a million for this article. I will use it as a base questionnaire for a project we are embarking on for an NGO and get the developer to crit himself against this if I may.

    Kind regards
    Jo

  • Allison Roth says:

    Enjoyable read. Truth can be the most fun!
    Two typo’s remaining in Conclusion – you(r) & driven?
    ๐Ÿ™‚

  • mezu says:

    “Code worship is blasphemy”?

    Hahaha, almost fell out of my chair laughing. Very good points presented here. I think that devs should also learn to listen, heck that might be great for guy devs in the long run (improved listening to the customers/managers might mean better and improved listening with the GF/Wifey/Partner).

    In some cases, no amount of time you give to the the client will help you decipher what they are on about. Software development is tough.

    Ndaa!

  • Meshack says:

    Informative read. Ever thought of being a developer psychologist? You’d make a killing, i think. *grin*

    I always credit Prof. Ian Sanders for point 3 – http://www.cs.wits.ac.za/~ian/ (as much he screwed the fun out of my first first year (no typo there), he did emphasize an important quality for every developer.

    No. 4 is every developer i know’s speciality (proof: i just gave myself bad time estimates for a personal project. Failed to meet my own deadline)

    Sometimes you can’t help with the code worship though. If your juniors and/or bosses keep complementing you on how awesome your solution is every time you do something, you are bound to get big headed (i guess working for confidence killers is good for you sometimes). But james made a good point about dumb code. nice one.

  • Ben says:

    Are you kidding me? 70% coding, 30% planning? I’ve never worked a single development job where the boss/manager would allow time for planning. Give me a break!! They just keep poking at me over and over asking for time estimates when I really have no clue how long something will take because they forced me to skip the planning phase!

    Have you ever considered that these “godlike” developers are often forced into a rut of mediocrity because of a lot of the bullshit imposed on them? Then the managers try to save face by hiring a butt-load of QA and impose strict unit testing rules (as if that will fix crappy planning and implementation).

    This has got to be one of the most ignorant and disrespectful articles I’ve ever read. Even the non-godlike developers deserve a little bit of respect for TRYING to prevent projects from completely diverging off into a path of no return where even simple maintenance becomes impossible. God forbid you get a perfectionist trying to refactor things to be more intuitive.

    Good luck finding your modest developer.

    • Hey Ben,

      Thanks for the feedback, i value your opinion.

      I guess I’m one of the lucky few who’s boss/manager let them plan their work. You had some good points in your comment which i think i also covered in my post. I also think we have different definitions of the ‘god like’ developer. Cause to me that is that guy who cant take a suggestion, or some criticism, because guess what, he’s always right. Also if you can not take a little criticism then you have no business being in a “creative” career where your work is always open to criticism. You work by its very definition is your opinion of what the solution to the problem should be. And hey, maybe you could be wrong sometimes. I just get peeved with people that just refuse to be wrong.

  • Luca says:

    >Developers should never test their own software.

    I’m always testing my software with Unit Testing, Developers (using Unit Testing) should ALWAYS test their software. For sure you need also someone else that can help to see what your “tired” eyes/mind cannot catch because you were too much on the problem.

  • I think you’re right in your time/code ratio analysis (even if it may be just a bit exagerated). I recently had to start a product for a client, which would be developped by a team. By forbidding anyone to touch any keyboard for a whole day, we saved a few weeks of development …

    Estimations ARE lies, it would not be called “estimation” otherwise. The danger is not to be aware of it.

    For example, I use agile estimation techniques not based on time but on complexity of each unit of development (yes, you need to split the work in very simple tasks), and I give my boss regularly updated estimations for the team using a little remaining(cpl)*done(cpl)/spent(time), along with an accuracy based on the amount of data used to compute the numbers.

    Of course if your bosses doesn’t allow you to take time to think about what you’ll do, they just deserve bad work. And usually bad work will take more time than good work, because you’ll avoid the 70% crappy code just by thinking what you don’t need it. You’ll write less code, but just the code needed. Less code = less bug = more accurate work = efficience. And yes, computer science takes thinking, the coding process is just a finishing detail.

    Romain

Leave a Reply to Allison Roth Cancel reply

Your email address will not be published. Required fields are marked *

Page optimized by WP Minify WordPress Plugin