Balance Programming

Balance Programming

  • No comment code

    My last post mentioned No Comment Code and my initial horror at the idea. I’d not come across it directly before last year. However I think I’ve seen it’s influence on some other developers. I’ve done a bit of research but will be using Don’t Write Comments and To Comment or Not to Comment as…

  • Being explicit

    Last year I watched a YouTube video about “no comment code” which, to me, sounded like a terrible idea. A quick web search shows that not commenting code has it’s proponents. Let’s not get into that right now. While I didn’t agree with the video as a whole I did like one specific idea: Use…

  • Ninja coding

    Apparently “ninja” is Japanese for “one who is invisible” and that sounds appropriate to me. I’ve thought of ninja coding as going and changing something as the original author would do. The idea is to leave no indication, other than a commit history, that you were there. The same function can be written in all…

  • What is simple anyway?

    Keep It Simple Stupid (KISS) has been around for a while and didn’t originate in software engineering. There are several variations that replace the word “stupid”, people tend not to like being called stupid, but none of them say it as well as just Keep It Simple. I’m also going include about the related concept,…

  • A step too far

    One of the seeds for this blog was some code that I was reviewing. It was based on a recommendation by SonarQube. I don’t have it to hand but it went roughly like this: and was based on the rule: “if”, “switch”, and range-based for loop initializer should be used to reduce scope of variables…

  • How to manage a backlog?

    One of my friends had an issue with assumption that tasks rise towards the top of the backlog in a previous post. That is an assumption from working on Jira with a particular team and isn’t how backlog or tasks lists always work. Working with a prioritised backlog It’s very frustrating when you ask which…

  • We all make mistakes

    In some ways I don’t trust other coders but, to be fair, I don’t trust myself either. What I mean is, everyone makes mistakes, we should be tolerant of this and plan for it. It’s important to have steps in place to catch mistakes before they become problems. If someone makes a mistake I understand.…

  • Time estimation is hard

    In my experience estimating how long a software engineering task will be is hard. I think this is often the case with software engineering tasks in a way that it isn’t for other disciplines. More design than assembly A quick internet search suggests a beginning bricklayer might lay 250 bricks per day, an intermediate 450…

  • Markdown to PowerPoint

    When you writing documentation for your project Markdown lets you concentrate on the words rather than complicated formatting. You can take the same approach with PowerPoint. There are multiple tools out there which will do this. I’ve used marp and it makes very easy to make a presentation quickly. If presentations are a big part…

  • In one glance

    I’m surprised how often I come across large functions in projects. It’s not uncommon to come across functions with hundreds of lines. I’ve searched for something, jump in to the middle of a file, and then scrolled up desperately looking for the start of the function so I can start to understand what it’s doing.…