http://usersnap.com/blog/developers-lessons-learned/
8. Test first, release often.
11. Learn how to code no matter how old you are.
12. Learn how to say “No”
13. Follow other developer’s practices
I think the main thing there is just to use it – to practice and to get better at it, and to follow not so much the technologies but the practices that people are exploring. Staying on top of current practices at this point is really more important for us than technology.
14. Don’t be afraid to remove features of your product
http://henrikwarne.com/2015/04/16/lessons-learned-in-software-development/
1. Start small, then extend.
2. Change one thing at a time.
3. Add logging and error handling early.
4. All new lines must be executed at least once.
5. Test the parts before the whole.
6. Everything takes longer than you think.
7. First understand the existing code. 8. Read and run.
TROUBLESHOOTING
9. There will always be bugs.
10. Solve trouble reports.
11. Reproduce the problem.
12. Fix the known errors, then see what’s left.
Lesson 1: The best code is no code at all.
Open source and commercial products are another good way to avoid code. Despite what you
might like to think, you are not special. A lot of problems have already been solved by people a
lot smarter than you or I. And if their solutions don't seem to fit, then you really need to think
hard and justify why your needs are so different.
Software itself is actually full of code-avoidance mechanisms: subroutines, libraries, object
orientation, web services, virtualization, cloud computing. These all exist for the purpose of not
writing code. Use them.
As developers, it is hard to resist the temptation to write code. That's what we are here for after
all. But that isn't really your job. Your job is to help solve problems in the most effective and
prudent way that you know how. Code is just *one* of the weapons in your problem-solving
arsenal. So think about that before you write your next line of code.
Lesson 2: Code is for humans first, and computers second.
Lesson 3: You Are Not As Smart As You Think You Are.
More importantly, you must learn how to learn effectively. You must question your old
habits, seek alternative perspectives, and acquire knew knowledge. And just as important, you
must act on that knowledge. Otherwise, it is just trivia.
Lesson 4: Software development is 80% social and 20% technical.
The really hard part is figuring out *what*
code to write.
Figuring out what to write requires asking a lot of questions: What is the real problem we are
trying to solve? Which parts of the problem are constant? Which parts are subject to change?
How likely is it to change? Which are the critical features? Which features are fluff? What kind
of resources to we have available? The answers to these questions require conversations with
actual human beings.
So the message here is that to succeed in this industry, your social skills need be just as good
(or even better) than your technical skills. You need to be able to communicate with people and
find out what they really need, how they feel, what their history is, what their goals are, what they
are doing.
8. Test first, release often.
11. Learn how to code no matter how old you are.
12. Learn how to say “No”
13. Follow other developer’s practices
I think the main thing there is just to use it – to practice and to get better at it, and to follow not so much the technologies but the practices that people are exploring. Staying on top of current practices at this point is really more important for us than technology.
14. Don’t be afraid to remove features of your product
http://henrikwarne.com/2015/04/16/lessons-learned-in-software-development/
1. Start small, then extend.
2. Change one thing at a time.
3. Add logging and error handling early.
4. All new lines must be executed at least once.
5. Test the parts before the whole.
6. Everything takes longer than you think.
7. First understand the existing code. 8. Read and run.
TROUBLESHOOTING
9. There will always be bugs.
10. Solve trouble reports.
11. Reproduce the problem.
12. Fix the known errors, then see what’s left.
13. Assume no coincidences. When testing and troubleshooting, never believe in coincidences. You changed a timer value, and now the system restarts more often. Not a coincidence. A new feature was added, and an unrelated feature becomes slower? Not a coincidence. Instead, investigate.
14. Correlate with timestamps. When troubleshooting, use the timestamp of events as a help. Look for even increments. For example, if the system restarted, and a request was sent out around 3000 milliseconds before, maybe a timer triggered the action that lead to the restart.
COOPERATION
15. Face to face has the highest bandwidth. 16. Rubber ducking. Whenever you are stuck, go to a colleague and explain the problem to them. Many times, as you talk, you realize what the problem is, even if your colleague doesn’t say a word. Sounds like magic, but works surprisingly often.
17. Ask. Reading and running the code is often great for figuring out what it does and how it works. But if you have the possibility to ask someone knowledgeable (perhaps the original author), use that option too. Being able to ask specific questions, and follow-up questions to those, can give you information in minutes that would otherwise take days to get.
18. Share credit.
MISCELLANEOUS
19. Try it.
20. Sleep on it.
21. Change.
22. Keep learning.
Get your priorities right. Implement essential features before playing with the more interesting, but expendable nice-to-haves.- Get your priorities right. Implement essential features before playing with the more interesting, but expendable nice-to-haves. I used to have a dynamically editable upload form with zebra striping and all, implemented as a generic JavaScript component. Very cool and fun to code. But the actual upload functionality wasn’t implemented for a week.
- Try to write reusable, abstract code, but don’t go over the top. Your code should survive minor specification changes, but it doesn’t have to withstand a complete overturning of the project’s purpose. You’re not building a nuclear shelter. Before you go into developing a cool library completely decoupled from the rest of your code, pause for a while and try to assess what are the odds you will ever need this functionality somewhere else.
- Don’t use technical terms in user interfaces. Normal people don’t understand them. Be prepared to name interface elements in a way that seem illogical to you.
- Write it down!
- It's one thing to know you need documentation and peer review. It's another to know why. Without the latter, your application of the former will be useless.
- Without a clear description of the software requirements, not only does the developer not know when he's completed his task; he also can't possibly know that he hasn't completed it.
- Apply established standard formats for documentation rather than relying on ad hoc formats.
- Disastrous results can occur in an electric circuit when electrons follow the path of least resistance. The same thing can happen to a software product when developers are told to do the same.
- Following the path of least resistance eventually makes that path more resistant than the path of due diligence.
- Aggressively pursue opportunities to improve the architecture of the system.
- By forgoing peer reviews, your developers lose opportunities to learn from the successes, mistakes, and experiences of their colleagues. Consequently, your products aren't as robust, efficient, and maintainable as they could be. Read more.
Lesson 1: The best code is no code at all.
Open source and commercial products are another good way to avoid code. Despite what you
might like to think, you are not special. A lot of problems have already been solved by people a
lot smarter than you or I. And if their solutions don't seem to fit, then you really need to think
hard and justify why your needs are so different.
Software itself is actually full of code-avoidance mechanisms: subroutines, libraries, object
orientation, web services, virtualization, cloud computing. These all exist for the purpose of not
writing code. Use them.
As developers, it is hard to resist the temptation to write code. That's what we are here for after
all. But that isn't really your job. Your job is to help solve problems in the most effective and
prudent way that you know how. Code is just *one* of the weapons in your problem-solving
arsenal. So think about that before you write your next line of code.
Lesson 2: Code is for humans first, and computers second.
Lesson 3: You Are Not As Smart As You Think You Are.
More importantly, you must learn how to learn effectively. You must question your old
habits, seek alternative perspectives, and acquire knew knowledge. And just as important, you
must act on that knowledge. Otherwise, it is just trivia.
Lesson 4: Software development is 80% social and 20% technical.
The really hard part is figuring out *what*
code to write.
Figuring out what to write requires asking a lot of questions: What is the real problem we are
trying to solve? Which parts of the problem are constant? Which parts are subject to change?
How likely is it to change? Which are the critical features? Which features are fluff? What kind
of resources to we have available? The answers to these questions require conversations with
actual human beings.
So the message here is that to succeed in this industry, your social skills need be just as good
(or even better) than your technical skills. You need to be able to communicate with people and
find out what they really need, how they feel, what their history is, what their goals are, what they
are doing.
