Reading for personal development
Reading books to help develop your career seems to be falling out of fashion of late, especially in Software Engineering where websites, mailing list and blogs are used to fill the gap. I don’t think this is a completely healthy trend, as a lot of the best writing I’ve encountered on general software engineering, projects and people has been in books, not the internet. However I have found the internet, blogs and email lists to be infinitely better than books for providing solutions to specific technical problems e.g, how do I parse XML in C# 1.0?
I think this trend away from books has been partially brought about by the production and proliferation of books teaching about programming languages and technical issues which date quickly instead of the software engineering principles or design which have a much longer shelf life. I think this occurred because although at first it was possible for publishers and writers to keep up with the rate of change in programming languages, environments and technologies, it would seem that for the last few years the rate of change has been greater than the publishers could maintain, with a few exceptions. This has lead to a flooding of the shelves of bookstores with books on version 1 of language X when version 2 is the latest version and on Office 2003 when Office 2007 is now out. Online sources are much better suited to keep up with the latest news and developments for language/technologies and to provide up to date examples and tutorials. This does not mean books should be ignored but a lot of people seem to be assuming this.
Books that cover subjects like development methodologies, software design, design patterns, problem solving, testing, people management, planning, running teams and other non technology/language specific areas are a vital way to pass on knowledge and information to those new to industry. However, the increasing trend of relying on online sources is meaning that a lot of new starts in software engineering have not read the classic texts, unless forced to in university. By not reading these texts they miss out on learning from those that have gone before them and are thus doomed to repeat the mistakes of the past until they learn the hard, slow and inefficient way.
Part of my desire to start this blog was to have on it a recommended reading page, listing the texts I feel every software engineer regardless of platform, language or methodolgy should read in order to ‘stand on the shoulders of giants’ and avoid the bane of our discipline which is reinventing the wheel over and over again. I am currently working on the first pass of my list of recommended reading and hope to have it posted up in the next week or two.
Productivity: Learning productivity Programming Reflection
by Daniel
leave a comment
Reflection for improved performance
Regularly taking time to pause and then review and reflect on how you could improve, and then experimenting based on those thoughts is key to personal improvement and increasing productivity. This technique has really been highlighted to me since starting to use Agile development methodologies like Scrum where at at the end of each sprint (short iteration period) a retrospective meeting is held. These meetings allow those working on the sprint to pause, review and reflect on their performance during that sprint and to discuss how performance could be improved. The regular retrospective meeting is in my mind one of the most important innovations introduced by Scrum and Agile, as otherwise retrospective activities were limited to once per development cycle after shipping the product.
I think that those short development iterations and regular reflection sessions at the end of each iteration introduced by Agile/Scrum are perhaps the two components of these methodologies that help drive process improvement the most, but they are perhaps also the easiest to overlook. It would seem that the natural inclination for most workers (especially when stressed) is to not stop and think about how they are working, which means they do not truly understand their work flow and this limits their ability to improve their performance.
Some of the most productive individuals I’ve met, or have heard about, are those that regularly take the time to pause and think about how they are working not just about what they are working on and then experiment to improve. This habit goes against the instinctual urge most of us seem to have when ‘busy’ which is to not stop to think about the how as we think we don’t have the time to spare. This is a huge misconception, as taking time to pause and think about how we are doing things and how we can improve can yield large gains in terms of increasing productivity and reducing frustration.
Another overlooked aspect of reflection is that it can make a mundane repetitive task more interesting and stimulating by turning it into a personal challenge: can you tune your work flow and improve your performance on a set task? For example, habit can even be applied to repetitive manual tasks like mowing the lawn: can I mow the loan in a shorter period, where can I save time or remove repetition?
In summary, pausing and reflecting during your working day and then experimenting to improve can help drive a habit of efficiency which will increase your productivity and potentially improve the development process for your whole team, and this is what all development efforts need to suceed.
Explanations
I recently helped a co-worker explain a new concept to another co-worker, as they were struggling to explain it themselves even though they were experienced working with the technology they wanted to explain. This started me thinking afterward about the art of explaining something complicated without leaning on the established jargon for that subject, as the person you’re explaining things to is unlikely to know the jargon either.
During university I worked part time as an IT technician, which I think forced me to deal with explaining things to people without technical knowledge of the concept I was explaining. At first I was surprised at how unsuccessful I was at this and that got me thinking about why. Being able to explain something complicated in a manner where someone who has no technical knowledge can understand, is I think a very important skill to have as these sort of explanations will be required often in most sorts of careers. And often it is those who can communicate most efficiently that succeed more than those that are the most technically proficient, as what use is proficiency or ability if no one can understand you?
The key to becoming good at explanations has a few key parts in my mind:
- Paraphrasing while learning: When learning something new, it is highly beneficial to then paraphrase the new information in your own words. This practice has two benefits: first you will quickly find out if you understand what you’ve just read and secondly it will get you into the habit of thinking about the information using your own terms rather than just the terms in the texts (which is what you’d be doing if you simply memorised the text).
- Limiting your explanation: If you’re anything like me you’ll want to be as helpful as possible when explaining something, as well as exercise your whole range of knowledge on the topic at hand. This is actually the worst thing you could do, as if you think back to when you last learned something you’ll most likely realise you didn’t learn the whole subject in one sitting but by digesting it a piece at a time. When you are explaining something you are effectively teaching, which means someone else is learning and that means you need to keep your explanation short and compact in scope to give your student a hope of remembering it.
- Paraphrasing to verify learning: One of the best ways to check someone has understood your explanation is to ask them to paraphrase it back to you in their own words. This is not easy to do if they are not used to it so be patient; if it takes them a few attempts, they will improve with practice.








