Notes
A bunch of tweets and posts to my LinkedIn network. Juts random ideas collected here.
Some people in StartUps think that they should introduce test automation only once they have a product released to the world. I beg to differ. I think you can get that product to the world much faster if you start adding automation right from the beginning.
In the financial world there is a transaction buying the debt of another company. I wonder if one should be able to sell and buy technical debt as well?
Without constantly investing in good development environment you will soon have to wait 4 minutes every time you run a git clone. Who wants to waste time?
Dogfooding is one of the best things you can do to improve your product. Find a way for your engineers to be users of what they create and they will improve it beyond your imagination.
From idea to delivery in less than 4 hours a presentation and discussion about fast and reliable software development. CI/CD/Automation/DevOps
How to explain to organization that they don't need a DevOps team before they bring me in to set up their CI system and introduce them DevOps practices?
We use Jenkins to allow unprevilaged users to manually run certain tasks on our systems, but no one really likes it. What do you use?
Teaching #python at the Weizmann Institute of Science is really fun. A bunch of bright people who love to learn.
Using "foo" and "bar" in examples can be really confusing. Especially if the person sitting next to you is called Bar.
An old article on #Kanban in the operations team of @Spotify from 2010
If there is a #DevOps team it might be harder to improve the culture of the company as they already have an unrealistic idea about what DevOps is about.
Instead of wanting two more "resources" what about helping the people already on your team be more effective?
Make sure new employees and contractors know how to find their way around. Have an on boarding document that points out the what they need to know, where can search for answers and who to ask questions.
Three-person interviews generate more signal and meaningful meandering than traditional 1:1 interviews. via @orenellenbogen
In a restaurant, do they charge extra for cleaning the kitchen or is it included in the price? Same should be with #refactoring software. It should be part of the process and part of the estimated time.
An average software engineer will change companies every 2-4 years. The speed of distributing engineering ideas and practices is limited by that. Unless you make an effort to mingle with people from other companies or bring in consultants who go around like bees.
Why is continuous rebase better than merge at the end when the feature is finished? If it hurts, would you prefer many small pains, or an enormous pain at the end?
There is no conceptual difference between automated unit~, integration~, and acceptance~ tests. They all have the same formula: f(input) == expected output + bugs Only the size of f() is different.
No version control system can eliminate the need for developers to talk to each other!
For root-cause (or causes) analysis use the 5 Whys. Start with Wikipedia for an explanation https://en.wikipedia.org/wiki/5_Whys
The best way to learn something is to explain it to others. So make it a regular practice in your team to learn new things and explain them to each other.
While you want to pin down the version of every dependency of your project, you should also have a regular process to test your application with the newest versions of your dependencies. That will make it easier to upgrade.
What makes a good commit message? They key is to write detailed commit messages that explain why a change was made. Probably including the bug report if there is one. The how is in the commit itself and the verification is in the accompanying test. You do have tests, don't you?
Some may even be lucky enough to find themselves doing Extreme Programming, also known as The Scrum That Actually Works
When it Comes to Organizational Change, What Comes First: Technology or Behavior? - neither. They should go hand-in-hand.
An open letter to less experienced developers Some excellent thoughts on values and priorities. Especially interesting to compare the assessment of "writing code is the 5% of software engineering" vs the "only code matters" mentality of the Open Source world. Or at least part of it.
Shipping is a business decision, but making it sure you can ship is the responsibility of the engineering team. CI/CD and tons of tests can help you make sure you can ship any time without the fear of breaking the system. What’s the Value of CI/CD?
The only relatively safe way to make incremental changes to a software project is with a comprehensive test-suite.
Having nice code, maintainable code is not just a luxury software developers want. It also allows them to create value faster and with less risk to your clients and to your business.
When a company is purchased there is a lot of scrunity to take into account the financial debt of the company. Does anyone look at the technical debt as well? How can that be incorporated in the price paid for the company?
The time it takes to compile your software profoundly impacts the way people will develop. Reduce your feedback cycle and see the how developers can work much faster. How long does it take to compile your application?
Making Technical Debt Visible is probably the best way to convince management in the need to reduce it. Just show them how much firefighting costs each day. Show them the incidents.
When I visit companies to do contract work I usually encounter great difficulties setting up my development environment. Not only does it have many parts, it is also usually not documented. Now that I've started to work on a project for myself pretty quickly I wrote a README file that explains how to set up the development environment and how to run the tests even though I don't expect any other people to look at this code in the foreseeable future. I wonder if this is because my experience in Open Source projects where if you'd like any chance to get contributors you need to make it easy to set up a development environment.