WoSGamers welcome you again, the view faces, pleasing your body - thanking!

First thoughts on a new job

The first week of my new job has drawn to a close, and I thought I'd share a few thoughts on it. Perhaps this will help folks get a better idea of what to expect from some parts of the computing industry.

I'm working as a software engineer at a small company (<10 day-to-day employees), and it's developing a virtual environment medical training system. It's called Vertual if you want to check it out. It's not games development, although the actual background code draws a lot from the game dev discipline, hence why nearly all of us come from a games/graphics background.

My main task so far has been reading, which has included team documentation and policy documents. Even on such a small team, management and internal testing procedures are a big deal for everyone. (It's important that the company has ISO9001 compliance certification, as many customers wouldn't get funding approval if we didn't have that.) I was also directly encouraged to suggest any ideas I might have for improvements to existing policies.

As I understand the process, whenever anything is developed (including bug-fixes) a patch is submitted to our ticketing system. It's assigned to another dev for preliminary testing, and then for full code review (by another dev, if we have enough). It then goes to the lead dev, and if he OK's it, then it hopefully gets committed to the repository. This seems to be in stark contrast to some companies which are much more gung-ho with their dev-commit cycle.

The project's been around for quite a while now (nearly 10 years), and has customers worldwide. As such, there's a sizeable codebase already in place. That means a lot of my time has also been spent getting familiar with the engine that's being used, and understanding how it's been modified and used by the team. In other words, more reading!

I get the impression that developers are left very much to their own devices a lot of the time (as long as they're pulling their weight). That's certainly been my experience so far, and it's been very helpful as I've been able to set my own learning goals. There's freedom, but it comes with expectation and responsibility. That kind of environment probably wouldn't suit everyone, but I'm definitely enjoying it, and can't wait to get stuck into some serious coding. :)

Add a Comment

You need to be a member of WoSGamers to add comments!

Join WoSGamers

Comment by Kalakian on August 7, 2011 at 9:43: Sounds fun :)

Strange that you use SVN (my version manager of choice as well) as de-centralised source control seems to fit the work model better, but glad to hear it works well in that scenario. Was considering giving other team members only write access to our XNA engine, and asking them to submit patches if they want any changes made, rather than direct write access, but didn't know if it would work well ... thanks for the info! :D

Argh, perforce! That was my first introduction to source control, and I hope I never see it again as it's just awful. Open source SCMs ftw!

Comment by Peter Bloomfield on August 7, 2011 at 1:43: Oh yes, coding away as ever. Made a fully articulated robotic arm simulation on Thursday afternoon using the team's engine. It was a fun learning exercise. :)

The version control is SVN actually, which surprised me a little, if only because Perforce is more common in commercial projects. I suspect it's partly because the software started life as a research project back when SVN was the hip new open source kid on the block. (It's still my version manager of choice though anyway, albeit in a slightly love-hate kind of way sometimes!)

Comment by Kalakian on August 7, 2011 at 0:51: Great to hear it's going well there. Hope you're having some coding fun in-between all your reading :)

I'm assuming you're using something like Git or mercurial for decentralised source control. I've not used them myself, but they sound ideal for that sort of project. Personally, I'll stick with nice centralised SVN and hacky code rapid application development.

Comment by Peter Bloomfield on August 6, 2011 at 12:26: I think the age and maturity of the project has a lot to do with the testing/review procedure, at least as regards the main body of the software. All of the core functionality is there already (and has been for years), so most stuff that's getting done to the main trunk tends to be in fairly isolated areas. Each person's work on that kind of stuff doesn't really affect anybody else much (if at all), so they can happily work on it in their own working copy (or checkout) of the code, and only submit it for review when it's ready.

On a shorter/smaller project, where day-to-day changes can affect everybody, I think you'd be absolutely right. You wouldn't be able to work at that sort of pace, as everybody would be constantly waiting for someone else.

Comment by Scott Roberts on August 6, 2011 at 11:58: Glad its going well Peter :)

I'm curious though, if any change to the code base goes through 3 separate testing/review phases before its committed in a company of under <10 employees doesn't this substantially negatively impact productivity? I understand however the need to avoid introducing hasty or ill-tested elements and potentially de-stabilizing things. Not a criticism I'm just curious :)

Comment by John Sutherland on August 6, 2011 at 9:37: Ahhh ... I remember coding for a living. It was great fun and I highly recommend it to all our members. I am not surprised about the games and virtual reality. I came across the other way, from vr to games. The core skills are remarkably similar: graphics, unusual user interface, and strange AI.

Its good to hear it is being done properly, which perhaps explains why the company has survived 10 years. I have both hacked code and used Software Engineering practices in my coding life, and although it is annoyingly non-intuitive, SoftEng is the only way to write code properly. Indeed, I remember ISO9001 when it was a mere BS5750!