The next time you’re asked to do a coding test in a job interview, ask them why? If your potential new bosses aren’t able to determine from your CV and from talking to you what level of experience and understanding you have then you probably don’t want to be working for them in the first place. Take it from me, they’re just trying to fill headcount – this is fine if you just need a job (because let’s face it, sometimes you just need a job right?), but if you want a career then forget about them or at least as them “Why?”
I’ve had lots of interviews and I’ve given lots of interviews. I’ve never given anyone a coding test and I never will give anyone a coding test. The attribute that every coder must have is honesty – honesty to themselves firstly and realising that you are fallible as well as honesty to others and realising that what you build affects other coders, users and everyone who will come into contact with your solution. Having a nice portfolio is useful, having experience is perfect, but honesty about yourself and your abilities is more important to me.
Spending an hour telling someone who is really not that interested in hearing it what polymorphism is, or the difference between an abstract class and an interface is a waste of everyone’s time. Do they not know themselves? What are they trying to prove by having you tell them? How does this help you fulfill the dead-end job they’ve got lined up for you?
Don’t spend the rest of your life working for idiots. One of these days I’ll be hiring.
Well, in the end it was a bit of a disappointment I suppose. Microsoft have announced a tablet computer in two flavours – ARM and Intel, in two form factors, with an integrated keyboard and stylus support. As a lot of commentators are saying it does raise a few more questions than it answers in some ways – not least how is this going to play with the hardware manufacturers that are Microsoft’s usual bedfellows?
As a point-in-time view though you have to say that Microsoft simply didn’t have any alternative. They have a semi-successful hardware business already, they have been shown the way by Apple with the iPad and the enormous sales potential. They are releasing a new operating system version with intrinsic pad support which also is backwards compatible with the existing desktop software. Microsoft and Apple agree with the rest of the world that there is a huge market in tablet computing and there is plenty of space for everyone.
The remaining questions are will it work and where will we be in a year’s time? Some of those versions mooted of the Surface may not. But is this seemingly scattergun approach to seeing what works going to be successful? I’m looking forward to seeing it more out of interest than anything else but with this profusion of interfaces – keyboard, stylus, touch, will that work? How will that work? We’ll only know when we get one in our hands.
However in the meantime it’s nice that wiki is already disambiguating the old Surface from the new one.
The amount of actual merging of Rosegarden for Windows that has gone on in the last couple of weeks has been minimal as I’ve been implementing the final features for Friendlier 1.0 Beta. And jazzing up the website and thinking about how I’m going to sell this thing. You’ll find out more soon but suffice to say Friendlier will not only be pleasing on the eye, but also pleasing on the pocket. You’ll also get some great benefits for being an early adopter. More details to follow soon on pricing and availability but I’m pleased to say that Friendlier is now feature complete for V1.0.
In the meantime I’m thinking more seriously about Git following this article from El Reg. Version control integration is going to be a core part of Friendlier and it seems there will be no avoiding Git and GitHub going forwards. I’m looking forward to putting those features towards V2.0.
A couple of things have come to my attention recently. Firstly the flawed concept that having a Key Man (or Woman) is a risk to your organisation. Secondly that as IT people we don’t spend enough time just getting stuff working.
Hierarchies tend to want to avoid globbing knowledge in one place – they want people to share, for the assets to be equal and for everyone to have enough time to go on holiday. No really, they do. They want bums on seats, they want square pegs and square holes – everyone wants an easy life and for everything to be equitable. This is because those in power are scared of vesting too much trust in one person and therefore keeping a modicom of control without having to actually learn anything or do anything themselves. They want to trust their staff and the best way of doing this is to ensure they keep talking to each other. Make sense doesn’t it?
So a few years ago the buzzphrase ‘key man risk‘ came about and suddenly we were all running about and trying not to learn too much, or making sure we spend enough time doing knowledge transfer so that no single person holds all the cards.
However, organisations are only as good as the individuals that are involved in them and people working in organisations are inherently lazy and inflexible. That’s not to say they don’t do a good job but people will always have a tendency to make their life as easy as possible despite what is mandated as being good for the organisation. This is as true for the boss as it is for the shop floor worker. Everyone makes all the right noises but when it comes to actually addressing problems and making tough decisions to mitigate these risks everyone would much rather not make them and just leave things the way they are because it actually makes life harder to make these changes. To reroute information or processes takes effort.
Hence all organisations will continue to suffer key man risk – it’s pretty much unavoidable. So if it’s unavoidable is it actually a desirable situation? After all – you have someone who can do the job, shouldn’t you be celebrating this rather than trying to obviate it?
Along with organisations that just work (any old way) don’t we want solutions that Just Work too don’t we? So this takes us to my second thought – rather than choosing and implementing different software paradigms or methodologies to help us manage complexity, growth and the future what happened to just getting things done. Just tackling the actual problem rather than planning our way around it.
This second thought is less well defined – it’s new and it’s raw. I will call it Solution Oriented Programming and I will come back to this shortly. Essentially there’s a link here between key people and getting things done – you take risks to make progress – and those risks may only be ones that you’re already carrying.
Interesting to read also on Slashdot about the possibilities of getting back to the hacker culture. Celebrating the fact that there are people around who can actually improve processes for you very very quickly. So indeed if you did want to eliminate that key man risk, if you did want to just get things done – perhaps you should spend a little time just listening to your local friendly neighbourhood hacker about what can be done and then act on some of those ideas?
Ok, so it’s time to merge the trunk revisions of Rosegarden onto the mingw branch that I’ve created which makes the Rosegarden for Windows build available. This process is done of course in Windows and traditionally I’ve used the excellent QtCreator alongside Tortoise SVN to handle the source control side of things. Aside from that and a little perl to ease the cogs a little it’s all done just like that.
This time though I’m making life a little bit more complicated. I’m using Codename Friendlier to do the editing and to run the builds. I’m using this merge exercise as a test bed for my other software – so see if it’s possible and fun to work in the new environment for this ‘Light’ IDE. I probably could have started this exercise a month ago but instead I fell down a rabbit hole with indenting and text highlighting and to be honest this has made me feel a lot better about using Friendlier. None of the features are finished yet but it’s quite competent at allowing me to edit and build stuff. Or so I will find out in the next few days..
Of course a lot of the software job is maintaining things. We don’t get to work on new code that often so we have to deal with code other people have written, or code that we’ve written a long time ago.
And how to best describe this activity? Well if you’re lucky, or if you’re clever and tidy, you’ll have made sure that the code is neat and well formatted, the functions or methods are not too long and heavily indented and you may even have defined unit tests (if you believe in that kind of thing) to help you modify the code without breaking things too much.
More often than not though the code you’ve inherited or having to debug is difficult to understand, badly formatted, and comes as if written by a cabal of rabid monkeys after a raid on a sugar factory. Indeed for the last few days I’ve had the pleasure of trying to track down a bug in some VB code which appears to be something to do with either file handles or database connection record sets going out of scope.
This isn’t made easier by the fact that we’ve recently moved to Oracle 11g. So this could even be down to some vagary of the ODBC driver memory management changing – or it could be something to do with a Microsoft security patch even. However before testing out any of these options (as that would require re-installing Oracle clients) I’ve been trying to track it down with good old debug statements.
However, I’m still stuck several days later. It appears that a CreateObject(“ADODB.Connection”) call will create a recordset ok – however the scope of the recordset seems to wave around seemingly at random. Well, perhaps tomorrow I’ll try another tack.
One of the more interesting things about writing an IDE from scratch because you end up at points where you can see how other people did things and making perhaps the same decisions as them, perhaps different ones. For example I’m just looking at indentation and bracketing in the text editor for Friendlier.
When you type in a closing brace in C++ or Java for example I would expect the formatting to work out that we’ve stepped down a level of indentation and adjust the text accordingly. Hence you are expecting to see a closing brace and then you can write it out with a command which might look a bit like this:
insertTextCommand(fileBuffer, someText, positionOfTheText)
And when the someText happens to be ‘}’ what can we do? Well we can change insertTextCommand to do something clever with the FileBuffer at the position of the text – or we can write another command that will do the formatting of the closing brace afterwards. Of course it’s useful to have a reformatting command anyway so shall we just have a generic command for reformatting a file? Probably not as formatting is target language specific (what may be a closing brace in one language isn’t the same as one in another) so perhaps we need a generic command which can be specialised per language we’re going to support somehow?
In Friendlier we already have a generic SyntaxManager class and specialise this to (for example) CppSyntaxManager. This handles text indentation, keyword highlighting, text completion and other functions already. We can pass this into our reformat command and it can work out what kind of text we’re reformatting:
reformatTextCommand(fileBuffer, syntaxManager, startPosition, endPosition)
So I can then run this command right after the insertTextCommand and it will reformat the text for me and best of all I leave my working insertTextCommand unsullied. Additionally if I don’t like the formatting that’s been automatically applied I can undo just that one command. Oddly enough this is exactly how Visual Studio appears to work too. I wonder if they code this in a similar way?
After a little fiddling I’m imported my Subversion repository to Mercurial and I’ve just started playing around with Easy Mercurial.
A long long time ago I was quite heavily involved in developing a piece of open source software called Rosegarden (the history of which is pretty well documented). It was, and still is, a piece of software that helps you compose, record and create music and it originally came into being during a final year University project that Chris and Andy did back way before when there was a Linux – back when everyone still thought Macs were just for accountants or graphic designers.
I got involved in the first steps of Rosegarden under Linux in 1995 and that snowballed into working on it full time for a while during the early 2000s. I’ve not been involved with the project in any big capacity since about 2006 but I’m pleased to say that the project is still going strong under the watchful eye of D. Michael McIntyre who has been the self-appointed custodian of all things Rosegarden since the rest of us swanned off to have children and do real jobs and have all the fun you can’t have when you’re sweating over an open source cookpot.
Rosegarden is now, what, about 18 years old? About to come of age or already there. Perhaps it’s coming to the end of the road, perhaps it just needs a nudge in the right direction? I’m keen to see it continue and I’ve been doing a small amount of work on a Windows version but the days when we could sit around throwing days and weeks and coding challenges are way behind us. Challenges need to be bite-sized, or life-sized, and Rosegarden might be just too much of a monster to continue. The last time I looked there were over 200k lines of code in there.
So the question is – where to now? And from a quick search I can see that Rosegarden is not the only Open Source audio project thinking the same thing. The question being is there any incentive to continue? Is there a will and if there’s a will – what is the way?
I’m ambivalent about Kickstarter for software projects because I’m not really sure who it benefits the most. For example I love the idea of Light Table maybe because that’s because I’m working on something similar myself (which, like Light Table, will be paid software) but I don’t want to take people’s money up front for it. However for a project such as Rosegarden – where there already is a popular piece of software there already and it’s looking for a way to survive – is this a more valid way for a project to fund itself? If so how should it be structured to attract and retain developers? Who decides who gets paid and how? To me the accountabilty and governance of a Kickstarter software project is still something of a mystery and perhaps we will see a backlash occuring at some point if and when projects fail to deliver? From the Kickstarter guidelines it is suggested that a project should ‘under promise and over deliver’. Perception is everything and with some big ticket Kickstarter projects currently running who is to say what the perception will be in a year’s time for crowd funding?
For Rosegarden perhaps nothing needs to be done other than a holiday for developers and a dose of enthusiasm. However structure always helps any development be it open source, commercial or both. Without vision and leadership things will drift and what helps to keep everyone sweet is an occasional pay day too. So – to Kickstart or not to Kickstart?
Today I’ve been finding out about this automated unit testing/JUnit thing that people do. Does it actually improve quality? Testing as a concept (to me, working in the industry) just seems like this sickness that is crept in for writing code twice or three times when you only want it once. Is the testing trade off worth the effort for non critical systems? I mean even with critical code there is a question of why we’re spending as much on testing as we are on development?
It of course depends on what code you’re writing and who is going to see it or its interfaces. I don’t think I’ve ever written a single interface that some other alien code will use – in that I always see both sides of the coin. If I were writing a public interface (anything web oriented) I’d be sure as dammit it worked to all tests and if it were to be maintained by other people I would put effort into constructing automated unit testing for it. However for most code I write I can see there is no point as it’s probably not going anywhere.
When you look at testing frameworks and dependency injection it is almost like test metadata is driving coding style. I think that an approach where dependencies are specified in constructors is a good way to code but this is after all only a coding approach. We will always find lots more problems passing structures into pre-existing objects rather than constructing them with those objects in the first place c.f. copy constructors being notoriously difficult to get right or say switching documents inside applications. And if you think logically about design then it follows that your objects should always be able to stand on their own with the minimum amount of dependency. Those highly coupled areas are always going to be the ones where problems exist anyway.
Isolating areas for test makes for progress and then refactoring (newish word which of course means redesigning) code to expose bugs and to fit better with the changed conceptual model ensures that things stay fixed and also code is easier to understand. So I’d argue that perhaps unit tests are just lazy ways of saying ‘need more work here’? And it’s all well and good to say ‘refactor’ but we don’t always have the time.
It’s very interesting learning about this – I can absolutely see the drive but again I just wonder why these languages are so complicated that we are forced to use complex frameworks to reverse park ourselves into good coding practices.