How to be a Good Developer

By George Fekete
We teamed up with SiteGround
To bring you the latest from the web and tried-and-true hosting, recommended for designers and developers. SitePoint Readers Get Up To 65% OFF Now

As a PHP developer, or any kind of developer as a matter of fact, you need to constantly improve yourself in this ever-changing industry; you need to learn and use new knowledge every day.

What successful developers have in common, is that they care about programming a lot, they are professionals treating good programming practices as a form of art.

In this article, you’ll learn about how to be a better developer by following the “etiquette” of programming and you’ll learn how to use this information to perhaps teach others to better themselves.

How to be a professional

Programmer's aid

Professionalism, regardless of the job you’re working on, always starts with you. Professionals first and foremost have strong personalities and characters.

As in any area of life, programming professionals are respected. Let’s see how you become one.

Don’t be egoistic

I’ve had the chance to work in large teams since I practice this craft and the most important team dynamic I learned early on is that team and collaboration goes hand in hand.

What you do most of the time in a team is learn from and teach each other, and the work environment should always embrace and reward sharing.

If you don’t want to share your work and knowledge, you’re arrogant and/or have a big ego, you won’t feel comfortable working in an environment like this.

Be responsible

Non-professionals don’t need to take responsibility for their own work. That’s left to the manager. They just get the job assigned to them and forget all about it when the clock hits 5 PM.

A professional programmer can’t accept this. How would you feel if your bug cost your company thousands of dollars?

This is a problem of which the solution also depends on management and how the company handles it. Every company should encourage developers to take responsibility of their actions and more importantly of the code they write.

If your bug slips onto the production server, do everything in your power to fix it as soon as possible, even if it takes all night long. This separates you from the nonprofessionals and gets you a higher paycheck.

Accept criticism

Software without bugs is impossible to write and we’re all victims of committing something stupid into the repository.

How we handle criticism says a lot about how we are looked at as developers.

Every criticism should be listened to and learned from, because that’s what makes you better at what you do, especially if you’re criticized by people who have way more experience than you do.

Have a strong work ethic

Being a professional is a non-stop job. Learning doesn’t last from 9 to 5.

Constantly learning, practicing and improving yourself is an investment in yourself and it’s your responsibility, not your employer’s.

This should also happen outside of work – you shouldn’t rob your employer’s time to read up on the latest SitePoint tutorials [Hey! Easy! ;) -Ed.].

There’s just not enough time, you say? Of course there is! You just have to think smart. If you want to take your career seriously, then focus on it seriously.

Get up early, leave a little bit late. Use those extra hours to your advantage without sacrificing your health and family.

Just half an hour before and after work means an extra five hours every week. That’s more than half an entire eight hour work day.

How to write good code

PHP Code

Read source code

Look at it this way: you can’t learn reading fast if you do not practice reading at all. The job of the developer is to write good code, but you can’t write good code if you don’t know what good code looks like.

Most developers blindly use third party libraries without touching the source code. This is okay to do, but to understand how that particular library can help, you need to dig in deeper and read its source code, the comments, run the tests (if it has any).

Reading code will help you quickly find other developers’ mistakes too and this helps a lot if you do code review or pair programming.

Learn new techniques

Always be open to learning new techniques and decide how they can help you be a better programmer.

Be open to new things all the time, don’t just dismiss the latest trends because you think they’ll pass. Everything is cyclical, but what’s constant is the knowledge you’re left with by opening your mind to it.

A good developer never stops learning, even with 15 – 20 years of practice behind him.

Slow down

Slowing down means to take a little bit more time on evaluating the problem you’re trying to solve. Being fast is not something you should strive for.

I’ve seen junior developers getting the task and delivering the code as fast as they could, resulting in buggy code, which took more time to fix than if they sat down and thought really hard of the right solution.

Senior developers are lazy and slow, and this is in everybody’s best interest, because a good programmer doesn’t want to do the job twice.

For a senior developer, writing the actual code takes up a third of his time spent on the task, the rest is thinking of a good solution for the problem.

Test your code

This won’t be a TDD or no TDD debate, but bear in mind that tests of any nature are very important for delivering quality code.

How do you know if something broke without testing it? Do you know what you were doing a couple of months ago on a particular feature’s code base?

From tests, you can learn how the code actually works. It’s like a guide for developers just as the table of contents of a book. Tests show you where to look and what to look for.

Writing tests for your code is important and hard at first, but it was proven to be beneficial in the long run countless times.

Know your toolset

Know what kind of tools you can use to help you fight the problem. Most of the tools, at the end of the day, come down to preference, but bear in mind that a good tool or library can help you out a lot.

Just think of how much time you spend in an editor, be it a full blown IDE or just a syntax highlighted text editor.

Also, you should decide whether it’s worth it to use a specific library for the job or not. Is it worth it to use a PHP framework? What are the pros and cons? Does using a clunky CMS for a project pay off?

These are the questions you should think of before even writing a single line of code.

How to stay on track

PHP Code

Fight burnout

Constantly pounding out code in a seemingly never ending cycle can be tiresome. Most developers who were in this business for long enough at some point in their career experienced burnout.

Burnout is associated with working long hours and what’s called the imposter syndrome, which means that a developer constantly thinks he’s not good enough and in order to be better he needs to work harder and to work more, while more doesn’t necessarily mean better.

The best medicine for this is to just step back, get out of that cycle and do other stuff, creative stuff. Take time off, even if it’s just a couple of days.

Another solution, increasingly popular in fighting burnout, is to find a team member with whom you can do pair programming. The social interaction with another human being is very effective.

Code maintenance

Staying on track also means keeping a clean code base. Not just for others, but for yourself, too. Code without tests or documentation is like Russian roulette.

What happens when you need to revisit some feature a couple of months down the road? You’ll spend more time figuring out what you were actually doing than on the task itself.

I’ve seen clients approaching developers to refactor their project countless times, because the previous team lost interest or couldn’t work on it anymore, and almost all the time the new team’s response was that it must be rewritten from scratch.

That happens because the previous team wasn’t capable of maintaining a clean, solid code base. This practice takes a lot of time; read the article called 18 Critical Oversights in Web Development which touches on how to keep code clean and other best practices.

On estimates

Estimates are a sensitive matter for many programmers and managers, and they shouldn’t be. I’m sure everybody heard of the case where managers ask developers how much time a task would take, and they expect clear answers, but the estimated task still takes up double the time that was initially estimated.

What most people fail to realize is that estimates are only guesses and not commitments. To be a better developer you should know that an estimate is never ever a commitment, because once you commit yourself to something, it means you’re responsible for delivering it.

Estimates never were and never will be commitments, this is the nature of an estimation. People are horrible at estimating time for a given task, and if your manager asks for this, you should tell him that you can’t commit yourself to something you’re not 100% sure of you can do on time.

You can, however, make a guess, but don’t make any promises.

How to be a master

PHP Code


It’s all about the communication. I’ve seen projects and companies fall apart because team members couldn’t communicate.

Keep communication simple and straightforward, cut out the middlemen between you and the receiver. Every “node” in your communication line creates almost exponential complications.

Enterprise suffers from this a lot – this is why it’s moving so slow, every decision has to go through a dozen people, and this is where agile teams shine.

Keeping communication simple and concise means you can move faster than others, you can understand your tasks more clearly and this gives you an advantage, so don’t be afraid to ask and to ask specific questions.


Besides being a good communicator you’ll also need to be a good collaborator, and let’s face it, programmers are not the most social people out there.

You need to collaborate not just with other developers, but also with your manager, and maybe directly with the client.

Collaboration also means knowing what’s at stake and to get the job done and to be a good team player.

If you find it hard to collaborate effectively with others, try out pair programming. The very essence of pair programming is collaboration.

See also this article on working with other people’s code.

The curse of knowledge

According to Wikipedia: “The curse of knowledge is a cognitive bias that leads better-informed parties to find it extremely difficult to think about problems from the perspective of lesser-informed parties.”

Basically, senior developers are having a hard time explaining problems so simple that junior developers can understand. This happens because they’re all very familiar with the problem and the techniques at hand to solve it, but when they try to explain it to others, they fail, because that explanation is just a summary of the knowledge in their head.

Simply put, when you know something, it’s very hard not knowing it. To fight this, you need to use specific language. Explain a problem in such detail that you find it funny even, but keep doing it, because your state of mind is not equal to the state of mind of the recipients.

Know your field

If you call yourself an expert in programming, then be an expert in programming. Know your field from top to bottom and don’t be afraid to say no as many times as you see fit.

To oversimplify this, being an expert is all about saying no to others, because that means you’re defending your truth, and having seniority among your peers, you’re probably right most of the time.

Knowing your field doesn’t necessarily mean you have a CS degree, it means you have a lot of experience and practice in what you do. You need to improve your skills not just in general programming, but in computer engineering and architecture.

Being an expert means you find the best possible programming design for a problem, writing code is the “side effect” of this.

Understand the business you’re in

Nobody can create good software without knowing the problems of the business and what they’re trying to solve with your code.

You need to be proactive and interested in the business, because that reflects onto your work. Without clear goals and specific problems the code will inadvertently be a mess, that’s how coding works.

You need to keep a tight leash on what features to implement and especially how, but for this the business value must be crystal clear.

If you feel that your expertise and the business’s goals do not align very well, then do yourself a favor and don’t accept the job. Value your time, because that’s priceless.

Code katas

To constantly improve yourself, first you must know at what level you are.

Code katas are exercises for programmers to improve their skills by practicing and finding better solutions for different problems.

You can try solving code katas at Project Euler, CodeKata or Topcoder.

Topcoder even offers prizes for finding the best solution to their programming challenges.


Programming is more a social skill than anything else. To be a good programmer, first you must work on your personality if you find yourself introverted. Then, master the programming principles.

You need to constantly improve yourself, to constantly learn, to be one step ahead of the game. To truly achieve professionalism you need to understand the business and the problem you’re trying to solve with your code.

Code is just a side product of the whole solution to the problem and it adds very little to the big picture. The ideas for solutions, the skills for collaboration and the mastery of the tools you need to use to solve a problem are the key to becoming a respected professional.

For more on becoming a professional, see this series, and if you have anything you’d like to add to this list, please let us know in the comments below.

We teamed up with SiteGround
To bring you the latest from the web and tried-and-true hosting, recommended for designers and developers. SitePoint Readers Get Up To 65% OFF Now
  • Tony Christopher

    I disagree strongly with you about professionals needing to constantly work more hours than they are contracted for. That’s a bad culture to encourage and is completely unnecessary. I work my 9 – 5, I read blogs at the end of the day to help me keep on top of the latest tech. I don’t put in an hours extra work every single day, but I’m still a professional.

    I’ve worked those 60+ hour weeks when a project is behind. I work overtime when I’m asked to, or I feel that it’s necessary for the project. But I’m not going to work it as a standard every single day, that’s the road to overworking yourself and burning yourself out.

    And if there’s a bug that I caused, I’ll fix it ASAP. I’ll even work overtime to do so if the bug is that bad, but I’m not going to kill myself working all night just to get it fixed. Nothing is so important it can’t wait a few hours to let me get some sleep.

    • You should probably read the section again; the statement was that “Learning doesn’t last from 9 to 5” and with that I totally agree.
      I find articles, like these, a nice read in the evening or on weekends. Of course not everyone is a total geek and has a life as well, no one will blame you for that. But it’s a nice way to get inspiration for the work week.

      George gets my compliments; I completely agree with him. Two enthusiastic thumbs up!

      • Tony Christopher

        My comments were directed to these parts:

        “you shouldn’t rob your employer’s time to read up on the latest SitePoint tutorials” – Employers should invest in their employees, not expect them to learn on their own time. Whilst I read some blogs in my own time because I do enjoy reading them, I also read during work time and don’t consider it stealing my employers time. I think such a comment is appalling.

        “If your bug slips onto the production server, do everything in your power to fix it as soon as possible, even if it takes all night long.” – Whilst I’ll work overtime to help fix it, I’m not going to lose any sleep over it. That mindset encourages burnout!

        “Being a professional is a non-stop job” – No, it’s not. Being a professional does not mean dedicating your life to your job! I work to live not live to work. I am a professional and such comments as these try to claim I’m not.

        • Oke, for these I’m mostly on your side. I guess I wasn’t reading the article as close to the letter as you are and feeling offended by it.
          Perhaps you shouldn’t take it as literally though; you state that you do enjoy reading reading on your own time. That is being a professional outside of the office and investing your own time in your own professionalism.
          I think the point is that you invest in yourself by continuously learning, and your employer profits on this and (I agree with you) should award this. Be it in payment or by allowing you to do so on office hours.

          • Paul

            There is a distinct difference between reading and learning in your own time for your own benefit, and being expected to do it for your employers benefit.
            Like the others, I strongly disagree with the culture of working outside of contracted hours. By all means do a little something if it’s what you enjoy, but do not do it to become a ‘professional’. If there was one thing I could improve in the development industry, it would be this widespread culture of being expected to do above and beyond what you are contracted to do. Unfortunately articles like this do not help at all.

        • Chris

          I also strongly disagree with those statements in the article. I’ve worked at places at either end of the spectrum, one company where I was an investment, and one where I was merely a resource.

          If your company takes issue with you learning on paid work time (assuming you are completing your work at a satisfactory level) then you are not valued long-term to them, and should probably look for a more worthwhile opportunity.

          Especially for junior dev’s, it is critical to breed the self-learning culture at work. You cannot force an employee to train themselves X hours a week outside of work time. You need to teach them not only do do this for their own good, but how to do it efficiently. That begins with experienced mentors in the workplace.

          I also agree that being a professional is not dedicating your life to your job. Unless you are an executive level employee, it’s a horrible life choice to dedicate yourself to your job non-stop. There’s a huge difference between being responsible and being rewarded for being responsible, and working non-stop. The latter is a great way to burn your employees out.

          I’ll also state that this article seems to make some large assumptions that professional developers work either for themselves or on very small teams. Most workplace professionals will work on team with other professionals, so if a bug slips into prod, it’s just as much on the QA team as it is on you. It’s dangerous to take complete ownership of everything you do from a quality standpoint, and can also become a big issue in team focused departments.

        • Lasse Rafn

          So, Tony, let me ask you this.: If the project you work on was a bit sloppy and the site starts bugging the **** out in production, for tons of users.. you would still go home at 5 sharp, rather than fixing the bug that could potentially cost customers/users? THAT is un-professional.. Sure, you don’t have to dedicate your entire life to it (I do, because it’s my passion) but leaving at 5 when everything’s on fire, is not professional.

          • Tony Christopher

            Nice to know you read my comments thoroughly Lasse. Did I not say that I work overtime when needed? All I said was that I wouldn’t stay up all night to fix it. If I’m still trying to fix the bug at 10pm, it’s better to get some sleep and come at it fresh in the morning than trying to fix it all night.

          • Melanie Reed

            I agree that when its on fire, that is an example of going above and beyond. This is the point I am trying to make (and maybe it is Tony’s also): in a normal world, its not 24/7. That is something artificial that’s been created by the greed for profit. And not acquiescing to that does not make a person immoral; it makes them saner. We have by this culture tried to redefine what is moral as to productivity. And Tony is right; more often than not the problem will wait. It generally is only an inconvenience. And the adventure can and will continue tomorrow after a good night’s sleep.

        • Melanie Reed

          Agree whole-heartedly! With this comment and your previous comment. I, too, have noticed the push to change the culture. The company needs to support the process and the process includes research (as in research and development). That is professional.

    • Sébastien

      100% with you. Also, spend time with my kids…or to be more ‘professional’…thats a no brainer.

  • Andj

    There are many things junior devs should learn from this article but don’t kill ourselves on overnight :v. New dev or juniors often run catching up techs/changes for every period of time and forgot learning programming principals those are absolutly required. It is more interesting if this article add the detail of programming principals and how to analize problems or make the code clearer, reusable and maintainable .

  • mehdi lamaafar

    thanks this is helpful and you forget to say main key of success in this domain is by be patient

  • Jamie Devine

    How am I supposed to know if I have ‘imposter syndrome’ or if I just am actually worse at this job than other developers?

    • I don’t know. I have never felt that way. Usually, when I find there is a new technology or programming language that I lack skills in; I either accept it and avoid working in it (Java), or I buy the best rated book on the topic from Amazon and immerse myself in it until I am highly proficient!

    • Lasse Rafn

      I have same problem. I don’t know SHIT about the technical terms (I have no education and I don’t bother with books; self-taught) but I do hell of a job when actually working.. Everyone else seems 100 times better than me when simply discussing but even though, my results always shine brightest and clients… well they’re standing in line to get my service :P Yet I still wonder if I’m actually worse than others, or they simply know some cool terms that make them seem good.

      What makes me feel this way, is the uprise of 12-years-old geniuses.. And then I sit here, at soon-to-be 20, and feel like that all those ours enjoying my life in my young years is wasted =D (enjoying my life = playing outside and having FUN)

  • Muhammed A K

    Great article George Fekete

  • Thanks for sharing informative information

  • What an excellent article sire, much obliged

  • Good article. Thanks

  • One of the best articles I have read so far. Thank you for sharing this with us!

  • Tim

    Too darn long, can’t finish reading it

  • Guest

    A good developer… is someone who can develop a product that when given… is exactly what the person who requested it wanted.

    A good coder on the other hand… is someone who writes code that when given… is exactly what the person who requested it wanted.

  • Md.Ibrahim

    Really liked it!

  • Very nice article.

    I think the bigger problem in my developer carrier is communication between developers themselves. They think that’s when the work is done that’s ok but without communication we can’t go forward and learn new things…

    Nothing is more important that to learn from others developers. It’s even better than staying one hour more in your workplace in order to learn more but alone.

  • Josh

    “To be a good programmer, first you must work on your personality if you find yourself introverted.”

    I would also add: “To be a good programmer, first you must work on your personality if you find yourself extroverted.”

    Not sure how one or the other is better or worse for a programming career. Both have useful qualities for the workplace.

  • fatzombi

    Thank you. :*

  • “To be a good programmer, first you must work on your personality if you find yourself introverted.”

    When I read that statement, I thought about some of the recruitment drives undertaken by larger companies for men and women with autism (I googled ‘ibm hiring autism’). In this instance, working on their personality would be way down their list of priorities. offers more of an insight.

  • Diamenta Princessa

    Kudos for Commodore cart at the top of this article :]. I’m coding in 6502 asm as well as it is so enjoyable to push the limits of 1MHz machine, challenges are defining our strength and it makes us pro. About learning, a code review is a key for me.

  • Youness Atki

    Thank you, great article.

  • Manuraj

    Nice article. Thank you George

  • Lasse Rafn

    Thanks you for this article! I’ll get back to work and read it, again, later :o) AMAZING read

  • Katheer

    I think this is use full to every developer, definitely I’ll Try to follow everything in my career

  • Omos Aziegbe

    A very nice and informative article. A very good read as well. Thanks for sharing.

  • Melanie Reed

    Agreed. Going above and beyond does not mean becoming a slave to the job or the company and frankly, that is what a number of companies want – especially from their female employees and unfortunately, they get it. Partly because women are trained and expected to do this and partly they are very subtly (and sometimes not so subtly) threatened with loss of job or pay. This is very bad long-term for morale and for just treatment of workers. You can do an excellent job without having to prove that personal and family responsibilities are unnecessary for your existence. ;)

  • yox64

    Great article! :)

  • gskema

    “You shouldn’t rob your employer’s time to read up on the latest SitePoint tutorials” – you got me :)

  • Good article!

  • Brad

    Good article. I agree with all points save one: Learning on the Job. Reading articles and catching up on new technologies should be part of a developers role. It benefits both the employer and the employee.

  • daydah

    Lovely article. On point. Thanks :)

  • Mr. XXXXX


  • Sukeshini

    Thanks for sharing these ideas. The best thing I absorbed is ‘constantly learn new things and practice’. Really worth knowing all these.

  • Gopinath Krish

    Good Article. . . Thanx

  • Oho it’s Me

    The communication is also important, agree (1)

  • Ssekubunga

    Great article!!

  • Md Rajib

    Nice article