161 reputation
3
bio website
location United Kingdom
age 30
visits member for 4 years
seen Nov 29 at 11:29

Enthusiastic computer scientist and somewhat sporadic author of articles for ACCU journals.

Likes: games programming, challenges, learning new things, code craftsmanship, watching people achieving to the best of their ability, Git.

Dislikes: untidy code, weak architecture, bad software processes, indifference, technological fads.

Very quick bio: My D.Phil. was in medical image segmentation. I then worked in industry for a bit, doing credit risk management at SunGard and software analytics/logic programming at Semmle. I'm currently working on object detection and tracking at the University of Oxford.


Sep
24
awarded  Autobiographer
Jan
10
comment Is it possible for a good programmer to have never used version control?
(To illustrate the point, it's not unheard of for hobby programmers who work alone on solo projects without team experience to be relatively better at code writing and architecture than at reading other people's code - they're doing the former a lot more than the latter. Conversely, a developer who maintains large codebases for a living but never designs a full system may sometimes be a lot better at reading foreign code than at architecture - same principle. Both can be considered "good programmers", they just focus on different skills.)
Jan
10
comment Is it possible for a good programmer to have never used version control?
Software development involves a number of different skills - e.g. code writing, code reading, architecture, VCS usage, etc. It's desirable to be good at as many of these skills as possible, and VCS usage is clearly an important one to be good at. Nevertheless, it is theoretically possible to be good at code writing, code reading and architecture without using version control. Not having ever used version control does suggest a degree of eremitism, and likely a lack of experience, but it doesn't tell you that someone can't write good code. The two skills are distinct.
Jul
24
comment Are unit tests really that useful?
@Mason: I entirely agree that trying to cover everything is crazy - I've tried it in the past and it simply doesn't work well. That doesn't mean that you can't cover the important things that you're worried might not work. When you focus on the boundary inputs to your functions, you're homing in on the things you think are risky. You can apply the same principle to your codebase as a whole and test the modules that you think are risky too. I've also tried this, and it's worked a lot better. I don't think it proves my code correct, but it lets me try my code out in isolation.
Jul
24
comment Are unit tests really that useful?
There's a world of difference between claiming that unit tests somehow "prove" that your program is correct (which is clearly nonsense) and claiming that they are still useful (which to my mind is very much not nonsense). If you habitually write non-working code, then the fact that you also write (quite possibly equally non-working) unit tests will not save you. That doesn't mean that tests are not a useful addition to code that is already good. You don't use unit tests to try and prove correctness - you use them as a useful sanity check, focusing on the boundary cases.
Jan
13
comment Senior developer role to architect role
As to the requisite amount of experience, I'm not convinced by the fixed time limit of ten years, but I do completely agree that people in senior roles need to have spent a substantial amount of time in the trenches first - otherwise it will be impossible for them to really understand the rest of their team, or to be respected by the people with whom they work. Actually, my personal view on this is that they should never completely leave the trenches :) Good leaders are not the ones who sit 30 miles behind the front while you risk your life to move their drinks cabinet towards Berlin...
Jan
13
comment Senior developer role to architect role
I agree that the architect should not be the person writing most of the code - but he should never forget how to write the code, in order to maintain the respect of his team. Neither should he design in a vacuum without listening to the ideas of the developers and working with them to firm up a design. A good architect will appreciate the difference between being the lead designer and the only designer. Good leaders in general listen twice as much as they speak.
Dec
11
awarded  Teacher
Dec
11
comment How can a new programmer impress the software engineer (boss)?
And before Software Monkey directs the same point at me as at Steven...I have upvoted Mason's answer :) Just wanted to put a slightly different slant on things.
Dec
11
awarded  Supporter
Dec
11
answered How can a new programmer impress the software engineer (boss)?