Concluding the series of behaviors that will make us better developers, today we focus on the pleasure of making the project moving forward and on some suggestions of books and articles to read.
We have seen in the previous article that we should retain the urge to add extra stuff while we work on a specific feature and to avoid coding features just because we can. Then, what should we do with all these great ideas when they come? How to insert them smoothly in the process ?
It may seems obvious but writing the needs in the backlog is the best way to have them considered and prioritized. The worst thing we could do is to have an interesting idea expressed only in oral form. Not writing them is the guarantee that the questions will just come back every now and then, cluttering our minds and polluting actually needed discussions. Nobody wants to discuss the new UT framework in a meeting about sound design.
I have met developers and project managers who would tell us that there was a lot of things to do. “Which things?” would we ask, to hear every time the same answer: “A lot of them, I could give you a list!”. We actually could have used a list but never saw one. The problem was that since nothing was written anywhere, these people became overwhelmed trying to remember them. If we pushed hard enough they could tell one task or two, but never more. They knew there was other things but could not remember them nor could they figure if it was already addressed or not.
Our goal as software developers is to convert an idea to an exploitable product. We are certainly not employed to turn five requirements into twenty open questions. So when one question, bug or need occurs, we must handle it. We must expose it to the product owner, provide a hint to an answer if we have one, let him decide its priority, and follow his decision. If an idea is accepted, we should not bring it back for discussion. If it is refused, we still should not bring it back.
The point is that we should not leave a question pending; we must do something about it. According to the timing when the remark is done it may be more efficient to do it immediately, typically for the feedback of a code review or story testing. In the general case the minimal thing to do is to write it for future observation.
Some things are still difficult or too hypothetical to be discussed efficiently; in such case it will certainly fall down toward the forgotten depths of the backlog. A good thing to do if the feature seems very important for us is to materialize it with a prototype so that everyone can judge on results, thus making the project moving forward. Leaving space in our schedules to allow some exploration is a good way to experiment our ideas, to illustrate our point and to bring interesting discussions to the team.
This active behavior is also appreciated outside the software development scope. A very good manager I have met had this tendency to do things when they were needed. The project was stuck because we needed feedback from another company? He would call them. An adapter was missing when the meeting started? He would be the one to get up and to find it. Working with him was a pleasure because he was a doer. We all should be doers, not tellers.
If you have read all the articles of this series, you are now ready to become a leader and a reliable, precise, meticulous and focused developer. I would suggest to continue reading some books and articles below in order to refine your skills.
Continue reading
The GPL release of DOOM was what made me understand that I can always learn and improve my skills. Take a look at its readme: https://github.com/id-Software/DOOM
Code Complete: A Practical Handbook of Software Construction, Second Edition, by Steeve McConnell, is a must-read book for every software developer. It covers every part of software construction and backs up its claims with numbers and very good references. This is an easy way to level up our skills. Ask your company to buy it, buy it yourself or find a friend from which to borrow it, then read it.
Clean Code: A Handbook of Agile Software Craftsmanship, by Robert C. Martin. This is an excellent book explaining with very good examples how to write code such that our readers and ourself understand it easily. It also provides a collection of code smells to help detecting when things are going bad.
Clean Coder: A Code of Conduct for Professional Programmers, by Robert C. Martin. This book is to human interactions what Clean Code is to the code. It explains through well chosen examples how to work professionally and to pull our colleagues with us to do the same.
The Perils of Future Coding, by Sebastien Sylvan. A clever explanation of the harmful effects of anticipating the needs. Very well written.
How to Hire, by Henry Ward. This one is a very interesting article explaining how to hire good workers and comparing the gain of hiring of doers versus tellers.
Cowboy Coders and the Hero Programmer Culture, by Noel Llopis. An interesting look at the historical interest of having heroes in the team and an explanation of why we do not want them anymore.
How to be a Better Developer, by Chris Reynolds. A reminder that we can learn and improve our skills by practicing, meeting smart people and being humble.