Be Excellent To Each Other

I dunno. You add something to the system that says Good Morning/Afternoon [username] when they login/logon (I never know which to use) and the users practically cum in their pants when they see it. You code a stock forecasting system that uses exponential smoothing to determin seasonal trends which emails the product managers when a spike in demand for certain items is close, so they don't get caught out for the third year in a row, and they ask why the system didn't do that before.

I swear most of the people I work with think programming is all about persuading the little man inside the box to do whatever they think is the right thing at the time. I should be used to this but it got to me today.

Also why does it look like there are too many m's in programming.

There are never too many m's in programmmming

You make it sound so saucy!

Get them to organise a coach trip to go see the Internet on loan to the National Science Museum.

THEN SHOW THEM ANGER.

I have similar experiences in my job. It started as a tech support job with a little bit of php stuff as an aside, but I'm now the lead (ok, only) web developer and when they ask me how long the next project will take to complete, they always seem surprised at the answer. That and they'll wonder why I can't give an estimate sometimes, despite the fact that no-one's told me what's actually expected.

Still, best job I've had

My boss thinks programming involves holding hundreds of meetings until you understand exactly what he wants, then you just go and press the 'computer do this' button and off it goes.

Also, he never realises that what he says he wants and what he wants are very different.

It's a bit like when I was a wedding DJ, we had a fucking wicket set of Martin lights, all controlled by a dedicated light jockey, and they looked fantastic and cost a fortune.
People always went nuts when we switched the £50 bubble machine on.

Me: "So do you want it to do x or y?"

Boss: "I'll leave that up to you"

Me: *Goes off and spends two days making it do x*

Boss: "actually can you make it do the other one"

Can't I just show them violence, tinged with a lack of self worth.

I love coding when I create stuff for myself. Users always seem to think that the pretty pictures look nice and add to functionality. Designers have it so easy.

Which is why you've made sure to abstract away the implementation of x so that y just slots into place.

On my projects, x is usually something like "book an aircraft flight" and y is "backup database". Tough to abstract that.

This could even go down to if person gets arsey on the phone x otherwise y. You'd need a checkbox, which they'd never bother to click.

And there was me thinking the life of a PA was something quite different.

Well simplistically, they're both tasks, so could both support an ITask interface which defines one method "DoTask()". That way the calling code wouldn't know or care what the actual task is, just that it supports a DoTask method. And with a bit of IoC and DI you could hand all the configuration off to a config file. Quite why you'd want to swap around Book Flight and Backup Database functionality (or give users who can book a flight access to backup a database) is a different matter - but meh.

EoaE is clearly an Enterprise Architect

I've seen codebases get seriously messed up from Too Much Enterprise.

Never mind the code base. On the system I am working on the database structure is a bunch of unrelated tables. All joins are done in inline SQL. The reason for this...... when the update scripts were generated for the DB referential integrity stopped the DB from updating related tables because the ID's did'nt match. So the decision was taken to abandon database design and do all business logic through code. Fucking great. I have never worked anywhere like it.

I once came across some code that managed to lose most of its performance by code caching...
So many abstract classes & hierarchical interface structures (getX calls base getx & so on down the chain) that loading the functions to do anything took longer than what the functions did themselves at the end of it.
Too much OO makes baby Jesus cry.

Yep, and god help the programmer afterwards who had to optimise it.

Thank you for the symphathy

To an extent, yeah guilty as charged!

I've certainly seen my fair share of "Enterprise" apps that were mind-blowingly badly engineered. The usual culprit is not the tools at hand, but the mis-application of techniques by so called "Senior Developers" (quite how anyone at the age of 25 gets to be a "Senior" developer is still beyond me) who are blinded by dogma and have no idea how to be pragmatic/useful.

On the other hand, I've also seen Absolutely Hideously Badly designed non-enterprisey applications. The last big one was a mouldy VB6 application - this thing stank to high heaven. It was almost 2 million lines of code dross, filled with huge switch-case and if/else statements, cut and paste refactoring, massive code duplication, was unwieldly in the extreme and nobody (including the original developer) had a clear idea of how the thing worked, let alone how it was supposed to work! It took six months*, but a colleague and I managed to convert (well, re-write) the entire stinking mess to .Net and by applying some architectural know-how got the code down to less than 200,000 lines and left a well documented, stable, robust and extensible system in its place.

Probably could have done it quicker, but you gotta love those day-rate contract rates

And I've seen beautiful enterprise architectures with soaring butresses and fairy towers turned to mud by bloody coders

I wish I had the Authrortaa to do this at my place. Seriously, one part of the application works on the basis that when an exception in a try catch is hit (which to be fair it always does) another try catch runs to handle it. I shit you not.

Wait, do we work together?

Ah, no. The app I sometimes work with was never rewritten

What you've described sounds ghastly! Although there's nothing wrong with letting exceptions bubble up the call stack as long as they do get handled eventually - the mantra usually goes "only handle exceptions you know how to handle" - using exceptions to control application flow is a massive no-no in my book, especially when you can control the flow by doing a pre-emptive check!

You can pass my phone number on to your boss - he may want to call me in a couple of years to help sort the mess out

It gets worse because the exception comes from the application looking for a response from a webservice. It is low on my priority list because it currently "works".

Last week I found this in BaseDAO.cs:

I found it when shipping the code from dev into QA. Funny that. Also note it's called DAO but uses Linq. Offshore devs: keeping contractors (like me!) in highly paid positions for the next twenty years.

All that "good" work those VB6 guys have been doing will probably see me well past retirement (I'd let 'em off the DAO name though - DAO hasn't been relevant for a long time and certainly never as far as C# goes, so calling a base class BaseDataAccessObject or DAO seems reasonable enough).

More like:

Boss: Do x!
Me: If we do x, y will happen.
Boss: That doesn't matter now. Do x anyway.
Me: K.
[two weeks later]
Boss: Oh my God, y has happened!

I'm so glad I'm an artist.

I've worked with contrators who, I am pretty sure, fuck things up on purpose so that they get re-hired simply because government departments have preferred contrctors who they don't need to go through the security clearence process with.

I really don't think I could do it. I hate going back to my old code after learning something new and realising what a prat I was. I take a lot of pride in what I do.

Contractors sleep on big beds made of money. It helps more than you'd think.

You'd think, but every client thinks he's a designer as well. If you know what you're doing, why are you hiring me again? You just can't win, though you do learn to be quite defensive in the face of idiots.

Some "contractors" are chancers chasing the £££ that some companies will throw at them, but not all. If you're good (and I rate myself as good) you don't have to do it that way, and getting the results your customers want gives you opportunities for repeat contracts and good references.



It's impossible to know everything in Software Engineering; it's a massive field anyway and people are always discovering new ways to do things so the chances are you'll always be able to look back at code and see how you can apply new knowledge to it. But that doesn't mean that what you wrote previously is complete rubbish. I have 5 golden rules I adhere to when working on a project:

1) It has to work (including adequate testing).
2) It has to be well documented.
3) It has to be as simple as possible, but no simpler.
4) It has to be easily understood.
5) It has to extensible.

Stick to those and you'll always write good quality code. Before Unit Testing came about, I clearly didn't write much code that was "testable" in the UT sense, however I was still able to test my code to prove correct behaviour. Now I can see old projects where UT techniques could be used, changes made etc. - but it doesn't mean I did a bad job in the first place. Things just change.

The money helps, also

@Malabar Front: Sorry, I really didn't mean that in a derogitory way. I do get so caught up in my side of things that it just seems the designers I work with just have to change the odd image here and there then they go back to messing about with CMYK levels, or something, for about 5 hours. I do realise that they are sometimes in the firing line when stuff doesn't work because code behind an image is faulty. For some reason users still think this is a designers fault.

@EoaE: Ahh, if only the company I worked in now took heed of any of the 5 points you numbered.

1: Alright it does work. To a fashion.
2: I'm sure I have a fag packet with the spec on somewhere.
3: How's this work again?
4: Run me through that again.
5: What's exstensisable?

I have never worked anywhere like it and hopefully will not for too long.

Am I the only one who admires coders who could fit the whole of Citadel, or Elite, or fucking Exile into 32K?

Hah, don't worry about it! I didn't think you meant it in that way at all.

Dear Doctor Glyndwr,

I would like to know how I can become a contraxxorz.

Sincerely,

Me

(Seriously though, how?)

In my case: by my current employer getting into financial difficulty, leading to call my contacts, leading to finding out my previous employer were suffering from the skill gap created when I left (that they never filled). So I took a sabattical to do a 10 week contract, which has since had a 6 week extension (and I have been made redundant in the mean time, so I'm hoping for more renewals). The contracting rate I negotiated is about double my old salary.

Because it's not your money.

Hah! Yes. It's actually double when I compare the gross amount in both jobs. In terms of take home it's well over triple, and my accounting firm Mr K. Dodd and partners have said I can spend it all and they'll work things out with the Revenue.

Have you not met Gordon Browns Ultimate Bitch Slap yet?
(or IR35 as it is technically called)

I used to work with a guy who contracted and got £800 a day. This wouldn't had been as bad if he hadn't previously been on a salary, left the company and then come back again.

Ahh, good old day rates The best I ever experienced was £1200 per day - shame it only lasted three months.