This is my personal blog. The views expressed on these pages are mine alone and not those of my employer.

Sunday, 30 September 2012

What I've learnt about professional software development


I've been professionally developing software for four years now and thought I'd reflect on what I've learnt over that time. I've gone for the traditional bullet-point style (hope you don't mind), and they're in no particular order.

Loyalty to your employer is good as long as it isn't blind


The software industry moves fast, but the systems at your current place of employment aren't as likely so. As soon as you feel like you've stopped learning in your current job, it would be wise to get looking for a new one. Too often people stick to a job for too long, only to realise their skill set has become irrelevant (VB6 anyone?). Therefore it is always wise to try your best to be in employment with skills that are currently in demand.

Know it's impossible to know everything, so concentrate on learning what's important (whilst knowing what exists)


Because the software industry is so large and constantly changing it's simply impossible to know everything. However it's equally important to not reinvent the wheel. So you should keep reading blogs, contribute to stackoverflow and go to as many user groups as you can. It's totally ok not to know everything about new technologies, just concentrate on what they can bring to your projects because good developers can learn on the job.

Get a fresh pair of eyes on your problem as soon as you've tried everything


As soon as you find yourself stuck with a particular problem ask one of your peers to take a look.  Don't worry about appearing stupid, your employer would much rather you be productive as soon as possible.  Too many times I've wasted time debugging a problem, only for a colleague to instantly know the solution. Also others have experienced what you haven't, so make use of it. When offered advice take it and ask questions.

Teach and be taught


Sit with your colleagues, write a blog, build up a stackoverflow reputation, but most importantly do anything which gets your thoughts peer reviewed. The only way you learn is by knowing you already don't know everything, or having a long held belief proved wrong wrong.

Absolutely everything should be as simple as possible


Your brain can only hold a handful of concepts at once, around about seven in fact. It therefore make sense that absolutely everything you do should be broken down into the most simple form possible. Read code complete, constantly refactor your code, and use source control to store the the reasons for your changes.

Users don't always know what they want


This is a big one. Users cannot always conceptually visualise what they want, and only get a narrowing of their requirements when they see something tangible. This is where methodologies such as Agile come into play, their iterative processes promote keeping the users in the loop, who can then crystallise their requirements before you've done too much work.

Ask prospective employers lots of questions (and) understand you can't trust recruiters to do this for you


When looking for new employment you should be interviewing the company as much as they're interviewing you. This means lots of questions. Use your experience to avoid previous employment pitfalls, ask them about the state of their source code and what they expect of you.  In fact you should have lots of questions that you've been collecting over your career.

As for recruiters, my experience is that many are only focussed on their commission and will do whatever they can in order to achieve it.  However there are also really good recruiters out there who genuinely keep your interests at heart.  When you cross paths with such a rare breed you should keep in contact with them even if not looking for employment, because you never quite know when you might need them.  I personally use linkedin to keep in contact, and have recommended the best.

Your experience


That's the end of my list, and hopefully I'll have a handful more points over the next four years.  Perhaps you think I've missed some big ones? Use the comments to share your experience, and perhaps I'll learn from you too.

Tuesday, 11 September 2012

Entity Framework and the InvalidOperationException

While recently developing against the Entity Framework I stumbled across the following InvalidOperationException:

The changes to the database were committed successfully, but an error occurred while updating the object context. The ObjectContext might be in an inconsistent state. Inner exception message: AcceptChanges cannot continue because the object's key values conflict with another object in the ObjectStateManager. Make sure that the key values are unique before calling AcceptChanges.

I was trying to insert a new record into a table that contained an auto-generated value. Due to the way the entity model wizard generates it's factory methods meant I had to provide a 'dummy' value for the auto-generated key.

For example in the following code the first parameter is required, even though the database will auto-generate this:

Employee newEmployee = Employee.CreateEmployee(0, "Jansen", "Jan");
context.AddObject("Employees", newEmployee);
context.SaveChanges();

It turns out however that you also need to manually update the model (.edmx) so that it doesn't use the 'dummy' value as the object's key within the ObjectStateManager.

To do this you'll need to open it as text (in solution explorer right click the model, select "Open With" and select "Text Editor").  Then navigate to the auto-generated property in the storage part of your model (within the <edmx:storagemodels> tag) and add StoreGeneratedPattern="Identity" as an attribute.

For example change
<Property Name="ID" Type="number" Nullable="false" Precision="11"/>
to
<Property Name="ID" Type="number" Nullable="false" Precision="11" StoreGeneratedPattern="Identity"/>

The StoreGeneratedPattern is an enumeration which indicates whether the column in the database needs a value on insert and update operations, and since it's auto-generated on the database it doesn't.  Therefore by specifying this on the attribute you prevent the exception being thrown.

Bear in mind however this manual modification needs done every time after adding tables or refreshing from the database.  For more information see the changes made to an .edmx file by the update model wizard.

Thursday, 6 September 2012

Stuck debugging? Leave it!

I'd like to share an experience I've recently had:


This has happened many many times to me since becoming a developer, and I've begun to understand that if I find myself against a brick wall I should leave it and come back to it later.

It isn't just me who seems to have come to this conclusion, in fact many developers are actually attempting to take advantage of it when planning projects.  In the psychological world this phenomenon is termed: The incubation effect

I believe this has a very apparent effect in the field of software development, and I'd say most have experienced this at least once, especially as our job is to solve problems not just code.  In fact there was recently a discussion over on Stack Exchange where most answers cite 'taking a break' as one of the best ways to get over programmers block.

The science behind this isn't concrete, however it does suggest the activity we do should be unrelated, and sleep is even better as it helps process the information of the day and solve problems. Which corroborates with my experience.

So next time you're staring at your screen blankly, littered with breakpoints, and you're no where near a solution you should give up and come back later with a fresh mind and a fresh perspective. What do you think?