How to be a Good Developer
7 отговора
0 прегледа
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.
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.
Пази се от мъдрост, неспособна да Плаче...
и от величие, което не се прекланя пред Децата!
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.
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.
Пази се от мъдрост, неспособна да Плаче...
и от величие, което не се прекланя пред Децата!
в отговор на Refurbished
#2
Re: How to be a Good Developer
1971, JPL
1) Understand and accept that you will make mistakes. The point is to find them early, before they make it into production. Fortunately, except for the few of us developing rocket guidance software at JPL, mistakes are rarely fatal in our industry, so we can, and should, learn, laugh, and move on.
2) You are not your code. Remember that the entire point of a review is to find problems, and problems will be found. Don't take it personally when one is uncovered.
3) No matter how much "karate" you know, someone else will always know more. Such an individual can teach you some new moves if you ask. Seek and accept input from others, especially when you think it's not needed.
4) Don't rewrite code without consultation. There's a fine line between "fixing code" and "rewriting code." Know the difference, and pursue stylistic changes within the framework of a code review, not as a lone enforcer.
5) Treat people who know less than you with respect, deference, and patience. Nontechnical people who deal with developers on a regular basis almost universally hold the opinion that we are prima donnas at best and crybabies at worst. Don't reinforce this stereotype with anger and impatience.
6) The only constant in the world is change. Be open to it and accept it with a smile. Look at each change to your requirements, platform, or tool as a new challenge, not as some serious inconvenience to be fought.
7) The only true authority stems from knowledge, not from position. Knowledge engenders authority, and authority engenders respect—so if you want respect in an egoless environment, cultivate knowledge.
8) Fight for what you believe, but gracefully accept defeat. Understand that sometimes your ideas will be overruled. Even if you do turn out to be right, don't take revenge or say, "I told you so" more than a few times at most, and don't make your dearly departed idea a martyr or rallying cry.
9) Don't be "the guy in the room." Don't be the guy coding in the dark office emerging only to buy cola. The guy in the room is out of touch, out of sight, and out of control and has no place in an open, collaborative environment.
10) Critique code instead of people—be kind to the coder, not to the code.As much as possible, make all of your comments positive and oriented to improving the code. Relate comments to local standards, program specs, increased performance, etc.
1) Understand and accept that you will make mistakes. The point is to find them early, before they make it into production. Fortunately, except for the few of us developing rocket guidance software at JPL, mistakes are rarely fatal in our industry, so we can, and should, learn, laugh, and move on.
2) You are not your code. Remember that the entire point of a review is to find problems, and problems will be found. Don't take it personally when one is uncovered.
3) No matter how much "karate" you know, someone else will always know more. Such an individual can teach you some new moves if you ask. Seek and accept input from others, especially when you think it's not needed.
4) Don't rewrite code without consultation. There's a fine line between "fixing code" and "rewriting code." Know the difference, and pursue stylistic changes within the framework of a code review, not as a lone enforcer.
5) Treat people who know less than you with respect, deference, and patience. Nontechnical people who deal with developers on a regular basis almost universally hold the opinion that we are prima donnas at best and crybabies at worst. Don't reinforce this stereotype with anger and impatience.
6) The only constant in the world is change. Be open to it and accept it with a smile. Look at each change to your requirements, platform, or tool as a new challenge, not as some serious inconvenience to be fought.
7) The only true authority stems from knowledge, not from position. Knowledge engenders authority, and authority engenders respect—so if you want respect in an egoless environment, cultivate knowledge.
8) Fight for what you believe, but gracefully accept defeat. Understand that sometimes your ideas will be overruled. Even if you do turn out to be right, don't take revenge or say, "I told you so" more than a few times at most, and don't make your dearly departed idea a martyr or rallying cry.
9) Don't be "the guy in the room." Don't be the guy coding in the dark office emerging only to buy cola. The guy in the room is out of touch, out of sight, and out of control and has no place in an open, collaborative environment.
10) Critique code instead of people—be kind to the coder, not to the code.As much as possible, make all of your comments positive and oriented to improving the code. Relate comments to local standards, program specs, increased performance, etc.
в отговор на Refurbished
#3
Re: How to be a Good Developer
get fucked...ама ти верно ли го прочете целото, а?
в отговор на ThunderFuck
#4
Re: How to be a Good Developer
хаха баси яката идея наливай им да четат докато броиш пачките. хитър си ти много. дай домашно и на рабин он обича много да чете.
в отговор на Refurbished
#5
Re: How to be a Good Developer
мноо дълго плюс това на английски. Значи да си добър тряя да имаш поне една еблива qa ка на работа, че цял ден без да мачкаш цици/путка и да ти направят свирка не става
---
---
в отговор на ThunderFuck
#6
Re: How to be a Good Developer
Интересно мнение. Не всичко му разбирам, но все пак благодаря, че го сподели с мен.
Най-важните срещи са уговорени от душите,
преди още телата да се се видели.
Най-важните срещи са уговорени от душите,
преди още телата да се се видели.
в отговор на korporativa
#8
Re: How to be a Good Developer
Абе еблива е, но е "заета". 
Ще търся други решения.
Най-важните срещи са уговорени от душите,
преди още телата да се се видели.
Ще търся други решения.
Най-важните срещи са уговорени от душите,
преди още телата да се се видели.