This blog post is part of the "Revisited" series.
I just finished the book Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days - Jake Knapp, John Zeratsky, Braden Kowitz. It describes the Google Design Sprint and how to run one.
The Design Sprint
The sprint gives teams a shortcut to learning without building and launching.
The sprint is a five-day process for answering critical business questions through design, prototyping, and testing ideas with customers. Developed at GV, it’s a “greatest hits” of business strategy, innovation, behavior science, design thinking, and more—packaged into a battle-tested process that any team can use.
Working together in a sprint, you can shortcut the endless-debate cycle and compress months of time into a single week. Instead of waiting to launch a minimal product to understand if an idea is any good, you’ll get clear data from a realistic prototype. The sprint gives you a superpower: You can fast-forward into the future to see your finished product and customer reactions, before making any expensive commitments.
This page is a DIY guide for running your own sprint.
Overview of the process
On Monday, you’ll map out the problem and pick an important place to focus.
On Tuesday, you’ll sketch competing solutions on paper.
On Wednesday, you’ll make difficult decisions and turn your ideas into a testable hypothesis.
On Thursday, you’ll hammer out a high-fidelity prototype.
And on Friday, you’ll test it with real live humans.
Full process can be found here.
"Michael Margolis and Alex Ingram had interviewed staff at cancer clinics, and with help from Amy, they told us how trial enrollment worked" - page 62
The bigger the challenge, the better the sprint - page 26
"Here are three challenging situations where sprints can help :
- High Stakes (before committing to any big changes and projects, the sprint will help to find the right direction),
- Not Enough Time (there is a deadline and the project requires good solutions fast),
- Just Plain Stuck (important projects are hard to start and a fresh approach to problem solving can help to find a way to start)."
The Decider must be involved in the sprint and below are some argument if the Decider is reluctant to spend 5 full days - page 31
- Rapid Progress, emphasize the amount of progress you'll make in your sprint: in just one week, you'll have a realistic prototype. Some Deciders are not excited about customer tests.
- It's an Experiment, consider your first sprint an experiment. When it's over, the Decider can help evaluate how effective it was.
- Explain the Tradeoffs, show the Decider a list of big meetings and work items you and your team will muss during the spring week. Tell her which items you will skip and which you will postpone, and why.
- It's About Focus, be honest about your motivations. If the quality of your work is suffering because your team's regular work schedule is too scattered, say so. Tell the Decider that instead of doing an okay job on everything, you'll do an excellent jon on one thing.
Recruit a team of seven (or fewer) - page 34
||Who makes decisions for your team ?
||CEO, founder, product manager, head of design
||Who can explain where the money comes from and where it goes ?
||CEO, CFO, business development manager
||Who crafts your company's messages ?
||CMO, marketer, PR, community manager
||Who regularly talks to your customers one-on-one ?
||Researcher, sales, customer support
||Who best understands what your company can build and deliver ?
||Who designs the products your company makes ?
||Designer, product manager
Nobody knows everything (Ask the experts) - page 70
"Instead, the information is distributed asymmetrically across the team and across the company. In the sprint, you've got to gather it and make sense of it, and asking the experts is the best and fastest way to do that"
- Strategy : start by talking to the Decider
- Voice of the Customer : who talks yo your customers more than anyone else? Who can explain the world from their perspective?
- How Things Work : Who understands the mechanics of your product?
- Previous Efforts : Often, someone on the team has already thought about the problem in detail. That person might have an idea about the solution, a failed experiment, or maybe even some work in progress.
Find Customers for Friday - page 119
"Recruit customers with Craiglist [...] The secret is to post a generic ad that will attract a broad audience, then link to a screener survey to narrow down to your target customers [...] We offer a small stipend or token of appreciation - usually a $100 gift card [...]".
Make honest decisions - page 139
"Sometimes when people work together in groups, they start to worry about consensus and try to make decisions that everybody will approve."
"During the sprint, Oscar had succumbed to camaraderie. He wanted to let the team make the decision. But the idea the team chose wasn't the idea Oscar was most excited about. Later, after the prototyping and testing were over, he reverted to his normal method of decision-making [...]."
Fake it - page 168
"But perhaps the biggest problem is that the longer you spend working on something - whether it's a prototype or a real product - the more attached you'll become, and the less likely you'll be to take negative test results to heart. After one day, you're receptive to feedback. After three months, you're committed".
Pick the right tools (Prototype) - page 186
- If it's on a screen, use Keynote, PowerPoint, or a website-building tool like Squarespace.
- If it's on paper, use Keynote, PowerPoint, or word processing software like Microsoft Word.
- If it's a service, write a script and use your sprint team as actors.
- If it's a physical space, modify an existing space.
- If it's an object, modify an existing object, 3D print a prototype, or prototype the marketing using Keynote or PowerPoint and photos or renderings of the object.
Small Data (Interview, Friday) - page 195
"Newton didn't read the sample pages that evening. Instead, he handed them over to his eight-year-old daughter, Alice. Alice read them. About an hour later, she returned from her room, her face glowing with excitement [...]".
"Alice didn't analyze Harry Potter's potential. She didn't think about cover art, distribution, movie rights, or a theme park. She just reacted to what she read. Those grown-ups tried to predict what children would think, and they were wrong. Alice got it right because she actually was a kid. And her father was smart enough to listen."
The Five-Act Interview - page 202
- A friendly welcome to start the interview
- A series of general, open-ended context questions about the customer
- Introduction to the prototype(s)
- Detailed tasks to get the customer reacting to the prototype
- A quick debrief to capture the customer's overarching thoughts and impressions
Checklists - page 232
"In the following pages, you'll find checklists for every part of your sprint. (You can also find these lists at thesprintbook.com)."
Another blog post on the "Revisited" series.
This time it's Clean Code written by Robert C. Martin. I highly recommend this book because as an experienced programmer, it describes exactly what I have in mind when I write software or when I read code. Martin expresses clearly what I generally admit and sometimes difficult to explain what is clean code (interestingly, I wrote "good code" as a first intention. But here we talk about clean code. Craftsmanship. Not just "good enough"). He gives a lot of arguments for each of his points.
There is also a comprehensive list of what the author thinks what bad code is ("smells"). These "smells" are the same thing as code rule checkers (PMD, Checkstyle, Findbugs, ...) that are run automatically within a continuous integration system.
You will find a word on the author, a synopsis of the book and the tips that are the most important to me.
About the Author
Robert Cecil Martin (colloquially known as Uncle Bob) is an American software engineer and author. He is a co-author of the Agile Manifesto. He now runs a consulting firm called Uncle Bob Consulting LLC and Clean Coders which hosts videos based on his experiences and books.
Even bad code can function. But if code isn’t clean, it can bring a development organization to its knees. Every year, countless hours and significant resources are lost because of poorly written code. But it doesn’t have to be that way. Noted software expert Robert C. Martin presents a revolutionary paradigm with Clean Code: A Handbook of Agile Software Craftsmanship . Martin has teamed up with his colleagues from Object Mentor to distill their best agile practice of cleaning code “on the fly” into a book that will instill within you the values of a software craftsman and make you a better programmer—but only if you work at it. What kind of work will you be doing? You’ll be reading code—lots of code. And you will be challenged to think about what’s right about that code, and what’s wrong with it. More importantly, you will be challenged to reassess your professional values and your commitment to your craft. Clean Code is divided into three parts. The first describes the principles, patterns, and practices of writing clean code. The second part consists of several case studies of increasing complexity. Each case study is an exercise in cleaning up code—of transforming a code base that has some problems into one that is sound and efficient. The third part is the payoff: a single chapter containing a list of heuristics and “smells” gathered while creating the case studies. The result is a knowledge base that describes the way we think when we write, read, and clean code. Readers will come away from this book understanding How to tell the difference between good and bad code How to write good code and how to transform bad code into good code How to create good names, good functions, good objects, and good classes How to format code for maximum readability How to implement complete error handling without obscuring code logic How to unit test and practice test-driven development This book is a must for any developer, software engineer, project manager, team lead, or systems analyst with an interest in producing better code.
Data Abstraction and Objects 1 (Objects and Data Structures)
"The beautiful thing about [...] is that there is no way you can tell wether the implementation is in rectangular or polar coordinates."
"There is a reason that we keep our variables private. We don't want anyone else to depend on them. We want to keep the freedom to change their type or implementation on a whim or an impulse."
"Hiding implementation is not just a matter of putting a leayer of functions between the variables. Hiding implementation is about abstractions! [...] Rather it exposes abstract interfaces that allow its users to manipulate the *essence* of the data, without having to know its implementation."
Data Abstraction and Objects 2 (Objects and Data Structures)
"Objects expose behavior and hide data. This makes it easy to add new kinds of objects without changing existing behaviors."
"Data structures expose data and have no significant behavior."
Use Unchecked Exceptions
"The debate is over."
"However, it is clear now that [unchecked exceptions] aren't necessary for the production of robust software."
C#, C++. Python, Ruby don't have checked exceptions and yet it is possible to write robust software in all of these languages.
"The price of checked exceptions is an Open/Closed Principle violation."
Don't Return Null (Error Handling)
"When we return null, we are essentially creating work for ourselves and foisting problems upon our callers. All it takes is one missing null check to send an application spinning out of control."
Don't Pass Null (Error Handling)
"In most programming languages there is no good way to deal with a *null* that is passed by a caller accidentally. Because this is the case, the rational approach is to forbid passing *null* by default. When you do, you can code with the knowledge that a *null* in an argument list is an indication of a problem, and end up with far fewer careless mistakes."
"Clean code is readble, but it must also be robust" (Error Handling)
Exploring and Learning Boundaries (Boundaries)
"Third-party code helps us get more functionality delivered in less time."
"Learning the third-party code is hard. Integrating the third-party code is hard too,. Doing both at the same time is doubly hard. What if we took a different approach? Instead of experimenting and trying out the new stuff in our production code, we could write some tests to explore our understanding of the third-party code. Jim Newkirk calls such tests *learning tests*."
Keeping Tests Clean (Unit Tests)
"From release to release, the cost of maintaining my team's test suite rose. Eventually, it became the single biggest complaint among the developers. When managers asked why their estimaes were getting so large, the developers blamed the tests. In the end they were forced to discard the test suite entirely."
"But, without a test suite, they lost the ability to make sure that changes to their code worked as expected."
"Test code is just as important as production code."
Clean tests follow F.I.R.S.T. (Unit Tests)
- Fast: Tests should be fast.
- Independent: Tests should not depend on each other.
- Repeatable: Tests should be repeatable in any environment.
- Self-Validating: The tests shoukd have a boolean output.
- Timely: The tests need to be written in a timely fashion.
Clean Systems (Systems)
"An optimal system architecture consists of modularized domains of concern, each of which is implemented with Plan Old Java (or other) Objects. The different domains are integrated together with minimally invasive Aspects or Aspects-like tools. This architecture can be test-driven, just like the code."
Optmize Decision Making (Systems)
"We often forget that it is also best to postpone decisions until the last possible moment. This isn't lazy or irresponsible; it lets us make informed choices with the best possible information. A premature decision is a decision made with suboptimal knowledge."
Systems Need Domain-Specific Languages (Systems)
"Building construction, like most domains, has developed a rich language with a vocabulary, idioms, and patterns that convey essentiel information clearly and concisely. In software, There has been renew interest recently in creating Domain-Specific Languages (DSLs), which are separate, small scripting languages or APIs in standard languages that permi code to be written so that it reads like a structured form of prose that a domain expert might write."
Getting Clean via Emergent Design (Emergence)
"What if there were four simple rules that you could follow that would help you create good designs as your worked?"
- Runs all the tests
- Contains no duplication
- Expresses the intent of the programmer
- Minimizes the number of classes and methods
The rules are given in order of importance.
Myths and Misconceptions (Concurrency)
- "Concurrency always improves performance."
- "Design does not change when writing concurrent programs."
- "Understanding concurrency issues is not important when working with a container such as a Web or EJB container."
- Concurrency incurs some overhead
- Correct concurrency is complex
- Concurrency bugs aren't usually repeatable
- Concurrent often requires a funddamental change in design strategy
Concurrency Defense Principles (Concurrency)
- Single Responsibility Principle
- Limit the Scope of Data
- Use Copies of Data
- Threads Should Be as Independent as Possible
History of JUnit (JUnit Internals)
"JUnit has had many authors, but it began with Kent Beck and Eric Gamma together on a plane to Atlanta. Kent wanted to learn Java, and Eric wanted to learn about Kent's Smalltalk testing framework. "What could be more natural to a couple of geeks in cramped quarters than to pull out our laptops and start coding?" After three hours of high-altitude work, they had written the basics of JUnit."
This blog post is part of the "Revisited" series.
I finished the book The Phoenix Project: A novel about IT, DevOps, and helping your business win, by Gene Kim, Kevin Behr, and George Spafford.
This was really, really interesting. Even though it is a novel (invented story), I could see a lot of real situations. I even laugh at some of them, because I could imagine what will be the following (e.g. They put a software in production even if everything is clunky and not working. Consequence : headline in the newspapers, and a lot of bug fixing).
Below is the plot :
The novel tells the story of Bill, the IT manager at Parts Unlimited. The company’s new IT initiative, code named Phoenix Project, is critical to the future of Parts Unlimited, but the project is massively over budget and very late. The CEO wants Bill to report directly to him and fix the mess in ninety days or else Bill’s entire department will be outsourced. With the help of a prospective board member and his mysterious philosophy of The Three Ways, Bill starts to see that IT work has more in common with manufacturing plant work than he ever imagined. With the clock ticking, Bill must organize work flow, streamline interdepartmental communications, and effectively serve the other business functions at Parts Unlimited.
I decided to revisit it, putting here some stuff that I found really interesting in the book.
Know what you are committed to (chapter 5)
Bill decides to know what is the Work In Process (WIP) before committing to any new projects. He and his management team establishes a list of every current projects, interviewing everyone working in the department.
This is important to know what is the current state, before talking about the future or any new projects.
If the actual tool doesn't work, change it (chapter 6)
There is a change management software in place. But nobody is using it, for many reasons.
Bill and his management team uses post it and whiteboard instead of the software. Everyone enjoys the new tool. It is interesting to not hesitate to think completely differently, even discarding actual non working tool for new working tool even it is not software. The right tool for the job. And then, improve constantly.
Have a common vocabulary (chapter 6, chapter 19)
In chapter 6, Operations are trying to find a way to track changes. And someone is asking : what actually is a change ? Then they spend the rest of the meeting to find and agree on a definition of "change" (same in chapter 19, but with the definition of "done").
All projects should have a lexicon, so team members can have a common vocabulary, speaking about the same things. This is quite important, and it is mentioned all throughout the book.
Learn from other industries (chapter 7, chapter 20)
"If you think IT Operations has nothing to learn from Plant Operations, you've wrong. Dead wrong," he says. "Your job as VP of IT Operations is to ensure the fast, predictable, and uninterrupted flow of planned work that delivers value to the business while minimizing the impact and disruption of unplanned work, so you can provide stable, predictable, and secure IT service".
Erik, chapter 7
"Obviously," he continues, "every work center is made up of four things: the machine, the man, the method, and the measures. Suppose for the machine, we select the heat treat oven. The men are the two people required to execute the predefined steps, and we obviously will need measures based on the outcomes of executing the steps in the method."
Erik, chapter 20
Don't be interrupted. Keep focus on your job. Remember the priorities (chapter 10)
In chapter 10, Bill wants to talk with Brent. But before poking him, he just sits and looks how Brent works.
Brent is constantly interrupted by phone call, e-mail, people around, ... and he always works on the last job given to him (later on the book, we find out that Brent is a constraint in the whole delivery process, because so many tasks depend on Brent).
The main point is, don't lose yourself in the continuous flow of work. Always have in mind the priorities and focus on most important tasks, the ones adding the more value. Project manager can shine here, protecting resources and people of interruption, keeping people focused.
Technology is evolving so fast (chapter 14)
Chris, head of Development department, is complaining about the rapid and constant evolution of the technology. However the book have no clear answer on this topic.
What I know, is that yes technology is evolving fast, but value is also about how people work. And what we can do with technology, delivering the maximum value to a client. When we are head of a department, the main objective is to know the features of a particular technology, what it is used for. But the implementation will be done by experts.
I am constantly looking at the news, trying to understand the concepts of new technologies and keeping ready to learn deeper.
Four categories of work : business, internal, changes and unplanned work (chapter 15)
The two first, business and internal, are pretty straightforward. I didn't think about changes as a work, because for me a change is part of a business or internal project. What I understood is that "change" in the book is part of the maintenance and not part of a project.
I already knew about the unplanned work, but the book emphasizes in order to understand deeply the problem with this type of work.
Work for the whole. Not discrete improvement
All over the book, different characters (mostly Erik) say that it is more important to focus on tasks that improve the whole rather than working on discrete improvements. That is the essence of the book and DevOps : drop the boundaries and look at the entire process, from Business, to Development, ending in Operations, and also Security. If you want to improve your organization, you need to improve the global process.
Wait time (chapter 23)
Eriks shows to Bill that most of the time of WIP is spent in queues, waiting to be processed. He draws a graph, showing how long a work can be wait in a queue and how destructive it could be for the delivery and throughput.
The wait time is the ‘percentage of time busy’ divided by the ‘percentage of time idle.’
This blog post is explaining it more in depth.
My conclusion based on what I saw and experimented is people can't be 100% on tasks (especially keep implementing new features). Saving time to improve tools, process, fixing bug can be very productive. Also if people are not 100% used and there is a peak of work in the project, it can be absorbed and processed by the same people.
Talking about private life (chapter 19)
Steve, CEO of Parts Unlimited, tries to build trust inside his management team (first step of the concept The five dysfunctions of a team). One of the exercise is to talk about something in his life, to get vulnerable.
It seems a very interesting exercise, but I don't really like to talk about my private life at work. I prefer to talk about technologies, innovation, how to do things, and trust someone on what he is doing or fixing. One can do anything he wants in his life, as long as he is doing a good job.
"The First Way helps us understand how to create fast flow of work as it moves from Development into IT Operations, because that's what's between the business and the customer. The Second Way shows us how to shorten and amplify feedback loops, so we can fix quality at the source and avoid rework. And the Third Way shows us how to create a culture that simultaneously fosters experimentation, learning from failure, and understanding that repetition and practice are the prerequisites to master".
Erik, chapter 7
The book quotes some methodologies :
Really good book ! Time for next one !
Étant actuellement en train de lire le livre The Pragmatic Programmer, j'adhère jusqu'à présent à tous leurs tips, mais certains m'ont particulièrement marqué car c'est ce que j'ai vécu dans mon travail et que beaucoup d'entre eux peuvent être appliqués dans la vie courante, en dehors de la programmation. C'est d'ailleurs certainement pour ça qu'ils m'ont le plus touché !
- Don’t Live with Broken Windows : Make sure to fix bad designs, wrong decisions or poor code as soon as possible.
Le plus important à mes yeux. C'est vrai dans son code, c'est vrai dans la vie. Dès qu'on laisse traîner quelque chose qui ne va pas dans un environnement, il se dégrade de plus en plus vite. Si on ne montre pas d'intérêt, alors les autres pensent que ça ne vaut pas la peine d'investir de l'effort. Il faut montrer l'exemple et corriger les problèmes que l'on peut voir.
- Don’t Assume It—Prove It : Prove your assumptions in the actual environment—with real data and boundary conditions.
Souvent les développeurs codent des algorithmes qu'ils croient être juste et l'affirment. Il ne suffit pas de croire et d'affirmer mais de prouver que cela fonctionne. C'est vrai aussi dans notre vie : discutez avec des gens et quand ils affirment une phrase (qui ne relève pas de convictions), demandez-vous et demandez-leur comment ils en sont aussi sûr. Vous verrez, les réponses sont parfois étonnantes...
- Provide Options, Don’t Make Lame Excuses : Instead of excuses, provide options. Don’t say it can’t be done; explain what can be done.
C'est tout le temps vrai. Nombre de fois dans mes premières années ou certains de mes collègues qui disent "c'est impossible, car ...", "je n'ai pas pu le faire parce que ....", et rester dans ce discours. Dans un projet, l'objectif n'est pas de justifier pourquoi cela ne fonctionne pas, mais de trouver une ou plusieurs solutions au problème à résoudre pour avancer (je me place dans un cadre opérationnel. Pas dans le reporting ou l'audit d'un projet).
- Be a Catalyst for Change : You can’t force change on people. Instead, show them how the future might be and help them participate in creating it.
J'adore le changement, la nouveauté et revoir la manière dont je travaille. Généralement quand je change d'outil ou d'environnement qui potentiellement change mes habitudes de travail, je m'en imprègne. Pourquoi a-t-il été fait ? Après avoir testé, j'adore communiquer mon enthousiasme sur ces nouveautés. Cependant, j'ai remarqué qu'il était extrêmement difficile de changer les gens et leurs habitudes. Il faut trouver les bons arguments. Ce n'est pas évident de garder la motivation si on est seul, mais la persévérance et la patience, ça paie.
- Design with Contracts : Use contracts to document and verify that code does no more and no less than it claims to do.
Les auteurs du livre en font souvent référence. Je pense que c'est un très bon tip. D'abord designer son service ou sa routine (paramètres, sorties, conditions, et encore mieux si c'est documenté avec des exemples) avant de coder l'algorithme. Quand les développeurs foncent bille en tête et ne prennent pas le temps de réfléchir à ce qu'ils veulent, ils perdent par la suite plus de temps à debugguer. Le Test Driven Development est une méthodologie qui permet d'aider à réaliser ce tip.
- Test Your Software, or Your Users Will : Test ruthlessly. Don’t make your users find bugs for you.
Indique que les tests sont obligatoires sinon on ne peut pas avoir un produit de qualité.
- Invest Regularly in Your Knowledge Portfolio : Make learning a habit.
Il est très important de continuellement apprendre. Nous sommes dans un métier qui évolue constamment. Il est nécessaire de suivre les nouvelles technologies pour pouvoir vendre ses compétences.
- It’s Both What You Say and the Way You Say It : There’s no point in having great ideas if you don’t communicate them effectively.
Rien de plus à dire, le tip parle de lui même.
- Don’t Program by Coincidence : Rely only on reliable things. Beware of accidental complexity, and don’t confuse a happy coincidence with a purposeful plan.
Sachez toujours ce que vous faîtes. Dans le cas où le programme fonctionne mais vous ne savez pas pourquoi, continuer d'investiguer.
- Estimate to Avoid Surprises : Estimate before you start. You’ll spot potential problems up front.
Estimer est une tâche difficile car elle implique une partie d'engagement. Pour moi c'est une tâche obligatoire. Nous nous devons de tenir au courant toutes les parties prenantes du projet sur le temps qu'une tâche/projet/développement va prendre. Mais attention : une estimation reste une estimation. Ce n'est pas un chiffre définitif. A la lumière de nouveaux événements, n'hésitez pas à reestimer.
Cependant, il y a des concepts et des designs qui subsistent avec le temps. C'est comme avec la philosophie : on ne jette pas les livres des auteurs du passé. On les lit, on les comprend et on les adapte/actualise. Et on s'améliore grâce à ça. On profite de l'expérience de ses aînés. On a beau dire, ce qui reste ce sont les écrits. Et ceux qui ont pris le temps d'écrire valent la peine d'être lus.
Vous trouverez ci-dessous une liste de livres que j'ai recensés et que j'aimerais lire dans un futur proche. Vous trouverez d'autres sites (ici, là ou là) qui ont des listes plus complètes.
- Clean Code: A Handbook of Agile Software Craftsmanship - Robert C. Martin (Non lu)
- Design Patterns: Elements of Reusable Object-Oriented Software - Gang of four (Non lu)
- Head First Design Patterns - Eric Freeman, Bert Bates, Kathy Sierra, Elisabeth Robson (Lu)
- The Pragmatic Programmer: From Journeyman to Master - Andrew Hunt, David Thomas (Lu)
- Domain-Driven Design: Tackling Complexity in the Heart of Software - Eric Evans (Non lu)
- Patterns of Enterprise Application Architecture - Martin Fowler (Non lu)
- Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions - Gregor Hohpe, Bobby Woolf (Non lu)
- Agile Software Development, Principles, Patterns, and Practices - Robert C. Martin (Non lu)
- Effective Java (2nd Edition) - Joshua Bloch (Non lu)
- Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation - Jez Humble, David Farley (Non lu)
- Soft Skills: The software developer's life manual - John Somnez (Non lu)
- Getting Things Done: The Art of Stress-Free Productivity - David Allen (Lu)
- Beginning Java EE 7 - Antonio Goncalves (Lu)
- Java OCA 8 Programmer I Study Guide - Jeanne Boyarsky, Scott Selikoff (Lu)
- Working Effectively with Legacy Code - Michael Feathers (Non lu)
- 101 Design Methods - Vijay Kumar (Non lu)
Vu le nombre de non lus, il faut que je m'y mette... Je reviendrai sur cette liste pour cocher ceux que j'ai lu !
Update 10/2015 : The Pragmatic Programmer terminé
Update 01/2016 : Ajout de Java OCA 8 Programmer I Study Guide
Update 04/2016 : Java OCA 8 Programmer I Study Guide terminé et certification en poche
Update 05/2016 : Ajout de Working Effectively with Legacy Code et 101 Design Methods
Update 10/2016 : Maintenant les livres sont sur mon wiki : https://hubesco.com/wiki/doku.php?id=software:books
Fil RSS des articles de cette catégorie