My article on Agile Principle #6 provides compelling points on why documents are the best way to communicate to and within a software development team. But how can we create and foster a document-driven communication culture in our engineering organizations? Define document expectations Engineers do not like ambiguity so give them clear direction. This means... Continue Reading →
Denmark’s Rooftop Solar Black Box
Denmark's energy infrastructure is controlled by a centralized authority known as Energinet. Energinet makes a lot of rules and regulations, and I recently ran into a problem with rooftop solar installation regulations. The below diagram from Energinet shows a recommended installation configuration for rooftop solar of size < 50kW peak: Energinet recommended configuration for self... Continue Reading →
South By Southeast: Copenhagen’s solar energy climate
The ideal direction to maximize the electricity production of a solar panel in Copenhagen is south and 3° degrees east (read more in my previous blog post). Solar panels in the northern hemisphere should get the most sun when facing due south, so now I am wondering what factors cause that 3° difference. I use... Continue Reading →
Carpe Diem: Copenhagen Solar Panel Optimization
I want to build a solar park in Copenhagen. I want to maximize my profit and I have already decided to invest in fixed solar panels that can't change angle. I also got a great deal for panel mounts fixed at a 45° tilt. But I am having a hard time choosing which orientation (azimuth)... Continue Reading →
Postmortem template for software engineering
If you just want the template then here you go! Otherwise, continue reading to learn more about postmortems. Why you should write postmortems The most important reason to write a postmortem is for your own understanding. The process of writing the postmortem will undoubtedly reveal areas where your understanding is not as deep as it... Continue Reading →
Design doc template for software engineering
If you just want the template then here you go! Otherwise, continue reading to learn more about design docs and templates. Why you should write design documents The most important reason to write a design doc is for your own understanding. The process of writing the design doc will undoubtedly reveal areas where your understanding... Continue Reading →
My Amazon story
This is a very different post than I usually write because it is for my benefit, not yours. I need closure on my Amazon experience and I hope by writing down what happened I can let it go and fully move on. The first eight months or so at Amazon were great. I was working... Continue Reading →
Driving consensus in an engineering organization
What is consensus and why is it important in engineering organizations? Engineers often need to solve ambiguous problems. Typically there is not a "correct solution" to engineering problems. Sometimes there is no good solution at all so a bad solution must be implemented. This is a difficult situation to be in as an engineer and... Continue Reading →
Don’t read “Domain Driven Design”
I read Domain Driven Design (referred to in the following as DDD) by Eric Evans so you don't have to! And you probably shouldn't read it regardless. DDD is a really ambitious book trying to establish a right way to develop software but it, unfortunately, falls short. I want software engineering books to improve my... Continue Reading →
Quick and Dirty Risk Management for Software Projects
Not many software engineers manage risk and even fewer know how to do it. It really is a shame because managing risk makes it much easier to set deadlines, meet deadlines and track progress. It doesn't even take very long! What is risk? It is the potential for something to go wrong. We already know... Continue Reading →