I managed to get 26 posts in 3 months but 52 posts has taken me more than 8 months. I’ve slowed down but that’s okay. My schedule has been regular which is probably better in the long run. I’ve never managed to get hugely ahead of schedule though. I think I’ve written a one or two posts a week early but generally it’s just a few days. It would be nice to be able to build up a buffer for the proverbial rainy day.
Over the time I’ve added a few new tools to my blog:
- My code samples are looking better.
- I can use diagrams if needed.
- My last post introduced embedded documents.
- During this post I’ll be passing the 50K word mark. That’s just a nice coincidence.
Posts 27-52
This is my line up since last time:
- Retrospective 27-52
- PowerPoint misfit
- Journey, destination and story
- Dream formatter
- Iterative development
- The Agile Manifesto
- Learning from… fine art restoration
- Image generation
- Design Patterns
- A brief history of Agile
- Is source control overworked?
- Maxims of comments?
- Mermaid diagrams
- Functional Programming in C++
- Forever change
- In what order
- Rust
- Dream debugging
- Learning from… jigsaws
- The Power of 10
- Apples vs oranges
- Time complexity
- Game Programming Patterns
- The taste test
- Data-Oriented Design
- Searching for design
I now break it down into both categories:
- Dream: 2
- General: 36
- Learning from: 2
- Overview: 3
- Review: 8
And tags:
- Acronyms: 2
- Algorithms: 2
- Blogging: 5
- Books: 9
- Builds: 1
- Debugging: 3
- Documentation: 4
- Languages: 2
- Methodologies: 9
- Organisation: 2
- Paradigm: 2
- Performance: 8
- Planning: 13
- Podcasts: 1
- Presentation: 1
- Standards: 8
- Testing: 2
- Tools: 7
- Videos: 1
- Websites: 2
I think it’s been another interesting range of posts and the only filler was when I caught COVID. I’ve tried a few potential series. The first looking at dream systems, that might be ones I admire or one I wish existed. I think that has a lot of potential. The second trying to learn from things outside of software development. I’m still not sure about this one. So far I’ve discovered more differences than similarities. I can still use that as a jumping off point to talk about software development techniques but maybe it would be better to just go there directly?
Thinking vs doing
In my first post I said:
This blog isn’t about some perfectly balanced programming practice. I don’t think that exists. Different situations call for a different emphasis. I want to talk about how to balance programming. How to think about what you want to achieve and how to pick guidelines accordingly. How to decide when to follow a rule and when to put it aside.
and in my last retrospective I admitted:
What can be hard is trying to avoid just saying how I do things. This blog is meant to encouraging thought about how to balance programming. I think my way of doing things has been good but that doesn’t mean it’s the best or right in every situation. I’ll try and keep my mind open to other ways of doing things. Often it’s about getting the right way to approach a post so I can mention more than just one solution.
Keeping the conversation just on balancing is still difficult. As this is a retrospective it’s time to review and then take action. While what I’d really like to do is primarily encourage thinking I don’t think that’s quite what I’m doing. Is this a bug or a feature? It’s my blog, so I get to decide. I’m going to revise my goal:
This blog isn’t about some perfectly balanced programming practice. I don’t think that exists. Different situations call for a different emphasis. I’m going to talking about programming, how I do it and why. That might be the right way for you or it might not. Think about what you want to achieve and what is needed for that. There are many software development rules and guidelines out there. They can be great, they can be terrible, they can even be both.
That faces up to reality of the sorts of posts I’m going to be writing. People should know what they’re going to get. I do want people to think about how to do things, ideally they learn to get better at that, but it’ll be done via reference to my way of doing things.
Being critical
In the last few months I’ve criticised a bunch of things: PowerPoint use, The Agile Manifesto, Design Patterns, Rust and Data-Oriented Design. That includes some big names and there are a lot of supporters of these out there. While it can be easy to criticise things that’s not what the blog is about. However looking at something and thinking through the details, that is what the blog is about. That might involve criticising or praising. While I don’t want to start programming in Rust it definitely has some interesting ideas and I’d love the option to use it’s match-statements. I’m glad to have been able to praise things recently as well: Functional Programming in C++, Dream Debuggers and Game Programming Patterns. Hopefully I can continue to bring both. That is often easier than coming up with something unique all by myself. Even so I’ve manage to write about: Iterative development, Commenting maxims and Dealing with change.
In the end
I’m proud to have stuck to my schedule and made it to this post.
Lets have a think about options for the next “sprint”:
- Saving pennies vs pounds
- Fixing problems vs causes
- Saying no
- Scrum
- Kanban
- Dangers of automation
- The Pragmatic Programmer review
- Wren review
- Remote work
- More algorithms
Until next time.
Leave a Reply