Maurice on Software

There are a huge number of articles on the web about "How to Comment Your Code" or "10 Top Tips to Comment Your Code". Having read a number of these I noticed the apparent absence of context in the advice given. Without a context it is easy to argue that one approach is better than another. Some people will argue that "all code should be commented", others that "if you write good code you don't need to comment". Both statements have value but without a context neither is right or wrong. In this post I'm going to discuss a number of approaches and suggest in what situation an approach is most suitable. Comment everything If you've ever used the Microsoft .NET Framework Class Library then you're most probably familiar with the MSDN style of documentation. You too can easily achieve this style of documentation, for your software, by commenting everything in your code and pointing a documentation tool (e.g. Sandcastle) at your

Often one of the most difficult, but important, things to say is "no". I've learnt this the hard way. As a junior developer, in my first job, I was so eager to impress that I said "yes" to most requests. Big mistake. Very soon I discovered that I didn't have enough time to do what I'd committed to and often didn't have the skills to do it either. Now it's not always easy saying "no". I used to worry that I was letting people down and that they would think I was being awkward. In the end though, I let them down so much more by not delivering on time or sometimes by not delivering at all.

I used to work with a developer who used to go to the toilet and come back with the solution to his problem. Now I'm not suggesting you spend your working day hanging around toilets (probably wouldn't go down too well with your colleagues), but the point is that by simply taking a few minutes break, and walking away from the problem, you'll be surprised by how often the solution will come to you.

Take a small amount of time each day to learn something new. Doing this every day will amount to a lot of learning. This might sound extremely obvious. However, if you don't make a conscious effort, to learn every day, it's easy to become complacent, and you'll soon find yourself lacking knowledge. This applies to most industries but is particularly relevant in software development, due to the rate at which technology changes. If you're lucky enough (or maybe not) to work on different types of project, and/or with the latest technologies, you might argue that learning is just part of the job. In this scenario you'd be right. However, there will be times that you have to work on the same project for a long duration of time. Usually, the start of the project involves lots of learning, there's a need for research, and you might prototype possible solutions. Learning is part of this process. When you come to the implementation stage though this naturally slows do

Updating your CV isn't just something you should do when you're thinking of applying for a new job. Updating your CV, especially the skills section, forces you to reflect upon what you've learnt over a given time period. This can have a number of benefits. If you find your skills are improving, either you've gained more experience in a certain area, or have gained new skills, updating your CV will give you confidence, and reassurance, that you'll be attractive to employers in the future. If you find your skills are staying much the same, over a period of time, it should provide the wake up call you need to re-evaluate your situation and make appropriate changes.

I overheard a conversation/argument a few days ago between two developers. At one point one of the developers said “well my product is greater than anything you’ve ever done!” It’s a shame the other developer didn’t respond by simply saying “prove it”. How could the first developer prove it? Proving whether a product is great or not depends upon how well the product fulfills its intended purpose . If a product was developed with the intention to annoy everybody who uses it, and it does, it’s a great product. If it doesn’t annoy the users, it’s not a great product. Of course, this would rarely be the intention for a product, but it illustrates a valuable point. A product doesn’t have to look good or work perfectly for it to be great, unless that was the intention

As I mentioned in The Beginning , I value my spare time. I’m not going to be able to spend loads of time writing lengthy posts. I’m also aware that, the lengthier the post, the less likely you are to read it. That said I am keen for this space to evolve and grow. I am going to use something I’ve decided to call Bites . These will be short sentences designed to stimulate thought on a certain topic. They might, simply, be a question, to which I will offer no answer, or maybe an observation. Whatever the format, the important thing to remember is that Bites will be as useful as you make them.