How to be a Good Developer

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

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

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

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

Communication

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.

Collaborate

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.

---

Conclusion

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.

Frequently Asked Questions (FAQs) about Becoming a Good Developer