Developer principles useful for other work
After decades of ideas for IT, here are some from it
Technology is abstract and often works in ways that are counterintuitive to the non-tech world. No wonder people tried to find metaphors to describe the work and principles and practices to make success more likely. I realized only recently that there is value in the other way around: Using ideas coming from Lean, Agile and DevOps that were originally meant for the tech part of value creation and applying them outside of software development.
Always have a deployable version
No matter what you are working on and how much time you think you have left: Always imagine that either the initiative gets stopped, an important stakeholder wants to see where you are or another opportunity comes up to show your work (e.g. an event, a sponsor with a spontaneous visit etc.). Yes, your work is valuable no matter how it looks. But whether you can get buy-in and support will be determined by whether you can show something on short notice.
If you are working on a new version of something that is already working, this should be a no-brainer. Never be without a working version.
Merge early, merge often
Yes, knowledge work is creative work, and it pays off to work on a topic in different ways - sometimes splitting into smaller groups, even working as an individual for a while. Nevertheless, the longer you wait until all different threads of thought and pieces of work come together as one again, the harder the integration work will be and the longer you cannot decide the next step looking at the whole picture. What risk level is acceptable for you? Plus, merging often enables you to show a new working version frequently.
Do not keep branches open for long
Ok, maybe for better understanding, rephrase this as "do not keep ideas as work in progress for long". The mechanics of the rule remain the same: Do not carry around an evergrowing list of ideas that "someone should work on someday when there is time for it". If you word it this way, you can be sure this time will never come.
For code, you either work on it, then commit it and get it merged, or you kill the branch where the code resides. You do not keep it "open" and "work in progress" for months. By then, the world will have moved on. Plus, the additional effort of remembering the idea and why it mattered will be higher than the potential value achieved. The same is true with ideas: If you cannot make them happen within a reasonable time (what that period is depends on what size your work items are), discard them altogether. You will get new ideas worth of your time. And if you discard a good idea, it will come back.
Single-person knowledge is deadly for stability and continuity
While it might seem like a recipe for job security to be "the only one who knows or can do this", in reality, it is a guarantee for running into trouble someday. What if you are on holiday or sick leave and the others working on the same topic need to do something that usually you take care of? Is there a more ridiculous reason for failure?
Having to get permission kills flow
Software Developers who need to ask permission for every single step to do their job lose precious time with waste. They are not acknowledged or appreciated as capable, professional people. The same is true for any other position: If you are not allowed to bring an idea fully to life, ask whether it is the right one - or if your team is the right one, because it seems you are not enabled to bring change. Maybe the people in the environment are unconsciously undecided - they want something done, but resist the idea that someone follows through with it. Get clarity about that. Do not waste your energy where it is not appreciated.
R.E.M.: Finest Worksong