Software Engineering Takeaways from YOW Conference
Attending conferences like the Yow! conference can be an enjoyable experience for software engineers and developers because of the wealth of knowledge and insights that can be gained from internationally recognized speakers.
The conference provides an in-depth look at emerging technologies and best practices in the software industry, without commercial hype. Through attending, one can gain enough knowledge to keep them satiated for weeks to come. Additionally, the conference provides a great opportunity to hear new perspectives and challenge one's current understanding, as well as learn from the mistakes of others.
The conference also promotes the concept of evolutionary architecture, which supports guided incremental change across multiple dimensions, and emphasizes the importance of learning for software engineers and architects to produce the best possible work.
Takeaway - In our discipline, there are a number of things we can call ourselves. Maybe we are software developers, or app developers. Maybe we are software engineers or maybe we are crafts people. Some people may refer to themselves as programmers. At the end of the day, Dave Farley wants us to see ourselves as software engineers because we are working on complicated, continually evolving systems and we need to continually solve problems.
“Engineering is about exploration & discovery”
- Dave Farely, Yow! Conference 2022
To be effective as software engineers, we must do a number of things. A simple but eloquent description that I had never thought of myself was that as engineers, the process is for us to find out where we are, take a small step forward, reevaluate where we are and repeat. I want you to remember that process.
During this process, we are likely going to come across decisions where you are unsure of the correct choice to make. At this time, you should take the path that is easiest to undo. In other words, the easiest to change. By doing this, we are aiming to create code that deals with change. This is why no code is perfect as perfect code does not change. As developers, we know that requirements change and therefore, our code must also be easy to change. We all mostly live by agile practices now as well so it really is the heart of what we do. Yow! expressed this simply as - we should write our code so that it is mostly correct today and can be easily changed tomorrow.
I think it is a pretty safe bet to say that there are more software engineers out there than software architects. The role of an architect is to protect the long term of a system. As someone that has been slowly becoming more involved with small architectural decisions on personal and professional projects, I think it is important that we challenge what we already know or what we are comfortable with. Despite this, as architects and engineers, I think we can universally say that there is no perfect architecture.
“If you don’t end up regretting your early technology decisions, you probably over engineered”.
Randy Shroup - Yow! 2022
At Yow! there was a new term that I had heard which I think makes perfect sense in 2022. This is called evolutionary architecture. So what is evolutionary architecture? Evolutionary architecture supports guided incremental change across multiple dimensions.
That sounds familiar right? Well it basically described an easy to change process that software engineers should also follow - find out where we are, take a small step forward, reevaluate where we are and repeat. Now of course there are complexities to both the technical solution and technical feasibility which goes into both sides of the field but it it is an easy process to apply to both disciplines.
To become the best engineers and architects that we can be, we should make sure that we know how to learn, both in new areas and from our mistakes. We should also try to maximise this learning so we can produce the best possible work that we can and not get blocked by things that we may not understand.
Easy enough? Well it is complicated. How can we optimise our learnings and understanding when we are surrounded by hundreds of biases? By recognising bias, it will allow us to look at a problem succinctly and pragmatically - like we should as engineers. For example, I know many reading this have fallen into the trap of the availability heuristic where the first solution that comes to mind on your problem is what you use. I personally have done this. By doing this, I know that we have regretted our decision as we started working without actually considering the needs of the new software.
One last thing that I want to share that ties with learning from the Yow! Conference is that even if you choose good architecture, even if you make iterative improvements to your system, and you did your research at the time, the outcome may not be great. This may not always be evident right away but you should remember that it isn’t always your fault. Technology changes everyday. What is the best decision right now may not be the best decision you can make one year from now and even if the outcome is less than desirable, it does not have to mean bad decisions were made.
Why we should all go to conferences
There are a number of reasons why I think people should go to conferences and why companies should assist with individuals who are wanting to attend. Personally I think there is a huge amount of information that can be used on a day to day basis for all developers. After Yow!, I have a notebook with over 30 pages of information, sketches, book and technology recommendations for tons of things that I have never heard of prior to the event (some of which I have integrated into my personal development approach a week after the conference).