SKA or what happens in 4DWW
The Experiment
In my current company we have a program called 4DWW (4 Days Working Week). It lasts 3 months in the summer, and - as the name suggests - you get in the working week a paid day to do what you want.
It was the first time for me, and I have to admit I really enjoy it. Actually this perks was among the decision points that push me to join the company, and I think, in retrospective, it was very successful. I felt like it was the Google 80/20 policy and the result is a project I think may be interesting for other engineers as well. SKA
BTW, this policy unfortunately seems will be retired in our company, and it's IMO a great loss, since those damn engineers (including me) really like to be a bit unleashed to produce great engineering ideas (better than mines), and the company itself ultimately will receive advantages from it.
A small engineering problem
For this 4DWW I decided to try to solve a small problem that I see happening consistently in every engineering organisation. When you work at a scale, you need standardisation and consistency. To achieve so, there is no better way to offer your engineers templates to enable them to easily scaffold (or SKAffold? 😎) projects or configurations and have out of the box something that works very well and they are ready to go.
So, usually, a central team (DEVeloper EXperience is always around us) starts preparing these templates, and engineers adopt them.
Now - or better, overtime - the DevEx team improve the templates (they are golden template but we all produce bugs, and fix them 😅) and those improvements should be distributed to all projects.
In each project based on the template, though, there might be files that have partially changed and out of control of the central team (has no knowledge about what might have change and it's important to keep).
Better not to break things you don't know about.
Then you end up that, after you scaffold (or SKAffold? 😎) your project, it's up to you - end engineer - to check what changed and onboard these changes. We all know it's never gonna happen, right?
SKA
In my 4DWW time, beside some gardening and DYI work at home I've decided to work on improving my Golang skills, and nothing better than have a practical project to work on to do that.
After a few weeks, I'm proud of release the SKA Project a scaffolding tool with support for central managed updates and better UI for engineers!
The demo below will show what you can do. The typical use cases I thought about it are:
- generate consistent file configurations
- generate consistent project repositories
- onboard updates for the above where the central team defines what is in their ownership domain and you can safely change all the rest
- a nice UI for collecting the information required to create your project
- GitHub and GitLab support (local file system as well)
Next
Well, it was a pet project, there are just a few tests so next iteration will be to extend test coverage (boooring...) to make it more robust when introducing new changes.
Then improve the CLI adding some helpers to add/remove ignores for files (already supported in the .ska-config.yaml) and get feedbacks.
If you want to give a try, it's available for installation via Brew. You can check this section in the README on the repo.