Balance Programming

Balance Programming

  • How often?

    Don’t Repeat Yourself (DRY) is, ironically, said quite a lot. I think in general this is uncontroversial. If you have a choice between writing a lot of very similar code: Or something smaller that does the same job: You are probably going to choose the later. Maybe you think this is an overly simple example…

  • AI assistance

    We now have access to new powerful tools like ChatGPT that can help us write code. There are a number of potential issues with this: So far I haven’t found this useful for situations at work. Every time I had asked for some source there were fundamental flaws with the code. It did sometimes give…

  • Historic programming style

    While researching one of my recent post I came across a reference to The Elements of Programming Style. It’s a study of programming style and it was first published 50 year ago. My dad recognised the book and he remembers when you had to make programs using punched cards! Despite it’s age a lot of…

  • Interconnection complexity

    This problem is sometimes referred to as communication complexity and can be a problem for teams. It also has implications for systems architecture and probably elsewhere. Team problem One person by themselves doesn’t have to worry about synchronising their work with anyone. There is no communication overhead. On the other hand, it’s just one person…

  • Good names

    Code is full of identifiers. Whether that’s variables, functions or types. If you’re doing something to something else chances are that one or both of those involve identifiers. I not going talk about how you format a name for the moment, whether you use camel case, snake case or something else. This is about the…

  • Building to throw away

    A lot of my advice here will encourage a methodical approach. I’ve worked on code that is more than a decade old. In that sort of situation the original author has probably moved on, perhaps most people who were working on the team at the time. Having comments and commit messages that explain what the…

  • 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,…