This month we've included everything you ever wanted to know about F# Active Patterns, why developers find it difficult to convince managers to let them 'do TDD', the results of GitHub's Open Source developer survey and a note on transparent salaries. Phew.
Kind regards, The Codurance Team
P.S P.S Missed our first newsletter? Catch up here
P.P.S Have you written something that you'd to share with the Software Craftsmanship community? Perhaps you'd like us to include a topic that we have yet to cover? Reply to this email and we'll try and make it happen.
Our opinion on... open financials and open salaries.
Since we started Codurance, we always wanted to have our employees involved with all aspects of our business. Besides trusting them as craftsmen, we would love to have their input on how to build a great company. In order to maximise everyone’s contribution, we felt that everyone should have access to the same amount of information, and that includes all the financials and salaries. Although scary, we knew that it was the right thing to do. So, 2.5 years ago we opened all our financials. From that day, every single employee has had full access to the company’s financials. This includes: Salaries, Revenues by project, Project contract details, Assets, Liabilities, Cashflow, Costs, and Taxes we pay.
Looking back, it was one of the best decisions we’ve made. That decision supported our culture of openness and transparency. Two and half years later and 3 times bigger in size, we can have very open conversations about the direction of our business, the importance of each client, we can discuss which benefits we can provide, we can openly discuss new hires, which investments we are all comfortable to make, and many other things. Codurance would never be the company it is today without the open contributions from all our people. There is no elephant in the room anymore and we can all focus on making our company a place that we all love.
We often get asked questions along the lines of 'how do I convince my manager to allow us to do TDD'. Sandro's blog post looks at why focusing on practices, rather than starting with solutions and working backwards, often holds development teams back from introducing new technical practices.
'For a theory even to be wrong, it must be predictive and testable and falsifiable. If it cannot be falsified - if it does not make some prediction that could in theory be tested and proven false - then it does not count as science.'
James Governor (Red Monk)'s look at how Amazon Web Services have been strategically hiring some of the most well know experts in the Software industry, and how this runs against the grain of the 20's hiring myth.
Daniel Lebrero attempt to empirically prove, via GitHub issues labelled as bugs across repos, as to whether static types produce more bugs. Includes interesting charts and a few takeaways in the conclusion.
Earlier this week, Sandro was invited to the Yellow Duck Podcast, a dedicated to software technology, developer problems and solutions. Catch Sandro's views on Software Craftsmanship, such as when it's appropriate to adopt or drop certain aspects of being a Craftsman.
GitHub teamed up with researchers from academia, industry, and the community to produce this survey on the attitudes, experiences, and backgrounds of those who use, build, and maintain open source software. Interesting reading.
Blog post from the GitHub engineering team on designing a new DNS infrastructure, aiming to improve operational issues (including scaling and visibility), as well as introducing some additional requirements.
Crafting Code course has been delivered to over 1,000 developers across Europe, introducing the ethos of Software Craftsmanship via Clean Code, TDD (Classicist and Outside-In) and techniques to deal with legacy code. Our new Crafted Design course brings these skills to a new level, purely focusing on the design aspect of software development, from emerging design through TDD, all the way up to designing micro services.