Sessions at JavaOne mostly are about technology Understandable, but there is more to creating software than technology. Creating great software also requires a lot of teamwork, managing, thinking and so on. The latter is a side often overlooked during conferences. Today we had one talk which was about the way we think, or maybe more about the way we think we think.
Double thinking system
The talk from Daniel Bryant and its corresponding title, are based on a book by Daniel Kahneman “Thinking, Fast and Slow”. Our brain has two ways, or systems if you like, to process information. System 1 and system 2. System 1 is fast, instinctive, emotional and subconscious. System 2 is slower, deliberate, reasoning and conscious.
We, as developers, tend to use our gut instincts (System 1) often. We often pick new technology because we remember it. We’ve seen people buzzing about it on the internet, we’ve seen it at conventions and we want to use it. Take for example microservices and docker. Both great technologies or ideas. But you have to wonder “is it the right tool for the job”, “are we not picking it because there are buzzwords and are hip”?
“When all you have is a SOA…”
“… everything looks like a service.” – Daniel Bryant
(Please avoid creating the toString() service)
Think professionally
You have to stop using System 1 so often, and start using System 2 more. It is hard, System 2 is lazy. You actively have to activate this system. Daniel spoke of constant learning; learn from mentors, read blogs and read books. Most people nowadays read blogs, often. Blogs are great to be informed of current developments, of new ways in which things can be done. Books often pick other topics, and are still very valid, years after publishing. Design Patterns: Elements of Reusable Object-Oriented Software is an older book (1994) but even now, after 21 years, it is still valid and a good book to read. There are book recommendations at the end of this post, both from Daniels presentation and my recommendation.
Use the software that is right for the tool and does its job well
We often pick a framework because it is familiar. If we do not pick it because its familiarity, we pick is because it is cool. You want to pick software because it is right for the job, but also because its documentation is good, it is actively developed. Maybe you want internationalization, does the framework support it? What type of services does it support? Raible’s Comparison Matrix can help you and your team to pick the right tool.
I know what the customer wants…
No. You do not. Most often, the customer does not know what they want. Creating software requires a lot of communication. During refinement processes you have to keep talking to the customer. He wants ‘functionality xyz’, you go about implementing it and take a look at it again. Is it truly what the customer wanted? Maybe the customer has had some new ideas, or maybe your implementation was not was they expected it to be. You constantly need to evaluate, with the customer, what you are creating. Software and its requirements evolve over time. Adapt to it and embrace the change. You will both be happier in the end.
Share the pain
A lot of developers create software, give it the operations and say “have fun with it”. When something goes wrong the operations team looks at the information they have and go “what am I reading here”, “what the **** is going on” at 03:00 AM. The next day they come to you wand tell you about it. You fix the problem and you are happy. Are they? You can guess the answer.
DevOps comes in handy here. Whether you are creating a team which holds each and every discipline, or you create deeper/better collaboration between the different teams is up to you. But a developer has to take responsibility for the code written. Do you like being called at 3 AM and hear someone say “fix this”? I guess not. It will make you think about the software you write, you do not what to be put in that situation.
And if the situation occurs, you want to solve the issue as quickly as possible. The first thing you look at are log files. A line you log must be useful. What were you trying to achieve, and what were important parameters in achieving that thing? Your log line needs to be as informative as possible. But do not log every single event or action taken. Only log points that are necessary. You do not want to go through 2000 lines of log lines which say “user entered the letter a into the field”, “user has entered the letter n into the field”.
Sunk Cost Fallacy
We do not like it when we are wrong. We not like it when we made a wrong choice. We like it even less to admit making mistakes. We all make mistakes. The worst thing you can do is blame others, whether it is the framework, hardware or a person. You make a mistake you are responsible for that mistake. Mistakes are a way of learning, we evaluate it and try never to make that same mistake again. Chose the wrong framework? Removing it is hard, but it is even harder to keep developing on the long run. Try not to ‘sink cost’ a mistake, once made it has to be rectified as soon as possible to reduce the damage on the long run.
Say no
A very hard thing to do is saying ‘No’ to your manager. “This application will be ready in two weeks, right?” We tend to say yes, even though we know it is impossible to do it in two weeks, maybe you’d throw in overtime to achieve it, you think. I hope you don’t. Saying “no” to such an estimate helps, but it depends how you say no. Just “no we will not make it” is not professional. Saying “No, we will not be able to give you all the functionality. But you will have functionality x, y and z and not n and m” helps. By giving alternatives you create conversation, in which a better estimate can be given. You start a negotiation on what is acceptable, and although the message is not a good one, it is the honest one.
Saying yes, but not being able to deliver is more painful. Will he trust you the next time he comes to you with such a question? Will you be as confident are before? Maybe the second time this happens, but definitely not the third time and forward. It makes you unreliable and impacts your confidence. You want to be as reliable as you can be. Being honest about unrealistic goals or estimates helps in creating mutual trust.
Learn to trust System 1
I am not stating that system 1 is unreliable. It is your first line of though. If your gut feeling says that something is wrong, trust it. Activate system 2 and think about what is going on, and why you have that feeling. And never, ever stop learning, reading and improving your skills.
Book recommendations:
- Thinking, Fast and Slow
- The Clean Coder: A Code of Conduct for Professional Programmers
- Clean Code: A Handbook of Agile Software Craftsmanship
- Software Architecture in Practice
- Lean Enterprise: How High Performance Organizations Innovate at Scale
- Extreme Programming Explained: Embrace Change
- Drift into Failure
- Software Architecture for Developers
- Work Rules!: Insights from Inside Google That Will Transform How You Live and Lead
- The Passionate Programmer: Creating a Remarkable Career in Software Development
I have not yet read all of these books, those not yet read are on my “to read” list which currently consist of over 400 books (fiction and non-fiction).
