Better software through software architecture and devops

@jamessnape

Tag Archives: #personal-development

  • Since I manage to read so much on the train I think readers will find some of the articles useful so I plan on listing up the best ones each month.

    Business Intelligence

    Databases

    Code

    Testing

    Development Process

    Personal Development

    Organisational Behaviour

    • The Open-Office Trap - New Yorker article rounding up all the research done one open space workplace productivity. Some interesting results among the expected ones.
    • Can-Do vs. Can’t-Do Culture - “The trouble with innovation is that truly innovative ideas often look like bad ideas at the time.” Next time you are thinking why something won’t work, take a moment to consider if you are stopping innovation.
    • Don’t interrupt developers - Absolutely nails why you should not interrupt developers.
    • Are Your Programmers Working Hard, Or Are They Lazy? - “the appearance of hard work is often an indication of failure” - a must read for both developers and managers.
  • My programmer personality type is: DHTC

    You’re a D****oer. You are very quick at getting tasks done. You believe the outcome is the most important part of a task and the faster you can reach that outcome the better. After all, time is money.

    You like coding at a H****igh level. The world is made up of objects and components, you should create your programs in the same way.

    You work best in a T****eam. A good group is better than the sum of its parts. The only thing better than a genius programmer is a cohesive group of genius programmers.

    You are a C****onservative programmer. The less code you write, the less chance of it containing a bug. You write short and to the point code that gets the job done efficiently.

    This entry was posted in agile  and tagged #personal-development  on .
    Discuss this on Twitter or LinkedIn
  • For some reason when I’m developing something new I always end up changing my design twice. Note, I’m not talking about architecture here. Architecture is a higher level concept and as such isn’t killed by implementation detail the way a design is. I think there is a reason for this multi-version development though.

    The first design is basically a prototype exploring possibilities. At this point I’m not sure what the best solution is or even what techniques might be best to use. It only just does the job and is probably not very elegant or efficient. Not something to be proud of.

    The second is usually a great design but, more often than not, flawed with a super hero style weakness. It will be elegant, efficient and cover every requirement imagined. The only problem – it will never be finished. This second iteration is usually complex, over designed and would take an eternity to implement.

    After a good dose of reality, the third version takes shape. It’s much more practical, easier to maintain and solves only the requirements that are actually needed. These three designs are usually quite different. Not what the XP crowd would call iterative implementations but the end result is similar.

    I think it’s important not to get too attached to any one way of doing things. I see some who start coding and stick with their first design to the bitter end no matter what. People often complain that a v1 product is OK for early adopters but not general consumption. Iterative design like this enables that sought after v3 product in your first release. Just don’t take three times as long to implement it…

    This entry was posted in agile  and tagged #iteration #personal-development  on .
    Discuss this on Twitter or LinkedIn
  • OK, I’m a little embarrassed to admit but I’ve suffered from coder’s block this week. It’s a state similar to writer’s block which is “a usually temporary psychological inability to begin or continue work on a piece of writing”.

    I think probably everyone suffers it from time to time and, although I haven’t had a case for a several years, this has come at a most inopportune moment because we are on a very tight schedule with our current release.

    I guess it’s a little like depression in that you can’t just mentally “fix it”, you need to work through the cause. In this case I don’t think it’s an inability to write code, it’s more a case of too many possible solutions to the problem in question. They are all good but none are perfect. In particular one of the requirements is to allow additional code generation (note – not just an add-in, this is adding to the system) post release by our professional services engineers. This is hard for me because my brain prefers to work spatially – I need to see the design animated in my head before I code it up; not something that’s possible if an unknown chunk of code if going to be added by someone at a later date. Talking with other developers didn’t help because all that did is give me more good solutions to consider.

    The other problem is that a number of very intricate details have to be thought about or the implementation won’t meet the requirements. Completely overwhelming if you look at them together so on Friday I decided to take a leaf out of the extreme programming book – baby steps. I started by ignoring the mass of requirements and implementing a really small section. By lunchtime I was back in the flow, I managed to check-in something yesterday evening and things are looking to be back on track.

    So if you are suffering similar then I can offer the following advice:

    • Take a break and do something completely different like go for a walk, however doing this too often is just procrastination
    • Try and work out what is causing the block and fix those issues one at a time
    • Take small steps to get something (anything) working
    • If all else fails, see if you can swap your feature with another developer
    This entry was posted in agile  and tagged #personal-development  on .
    Discuss this on Twitter or LinkedIn