I help companies automate and improve their workflows and systems.
If your company is helping make the world a better place, then you deserve to do so with minimal overhead and optimal efficiency. I'll help you get there.
I am going to drum the quality drum again. This is a big topic and I know for a fact that I haven’t even scratched the surface of what there is to say about it.
About a month ago I wrote
I’d like to admit, I never had a mentor or teacher who showed me how to properly document software. It was all learning by doing. If you don’t mind, I’ll take some future episodes of this newsletter to document (see what I did there? 👅) my findings and further thoughts about this topic.
This is one of these letters about documentation. My knowledge hasn’t grown by as much as I would have loved, but I read some interesting articles about docs. I want to share these with you.
You might remember that I told you about my “type”, the INTJ (Architect). Reader Gary wrote in to share his thoughts about that (quoted with permission):
So I’ve been busy at my client’s today. I had to implement a sidebar navigation with React. I did something like that a few years ago already and could now redo it for this client. This was great because I could build on my knowledge from the last years. And that’s why I got totally lost in time… I bet you understand. 😉
Last week we talked about quality, and how you could measure it in other’s projects but also your own. Today I want to think about how we can achieve a certain level of quality. But more important: How can we make sure we always achieve this level in our projects.
My brother reads these emails as well, and responded with some interesting thoughts re: quality. Shared with permission:
Aside from hard metrics that are often difficult to install, there’s also a lot of experience involved. I look into details like communication, discipline, timetables and overall presentation of the topic and the approach of the presenter.
Does it “feel” right/good/viable or are they just putting on a good show? One major category is the quality & depth of their questions and documentation. If those offer good quality and are well structured, I usually find the rest of it also well produced.
If you buy a piece of furniture, like a chair, you can compare it with all the other chairs in the exhibition. You can sit on them and compare how they feel. You get a feel for the wood, whether it‘s cheap or high quality.
How do you do that with code? Once the software is released you are able to compare and evaluate. But before?
When developing software you usually optimise for some aspect of the creation process. There are many things when considering a software development project like accessibility, usability, user satisfaction, delivery/deployment speed (release cycle), correctness of the code/app, developer happiness and many more. Some of these are first level concerns, some are on lower levels.
Today I want to share a small utility with you. I am a heavy user of Git, for years now. I am confident to use it on the command line, yet I still come back to using the application Tower (for Mac) regularly. Something about a visual representation other than the Terminal attracts me.
subscribe via RSS