Coding Horror

Capt'n Midnight wrote: »

Remind me of a conversation I had a long time ago.

The "programmer" didn't know that both .com and .exe were executables in DOS

Seriously, who didn't know that :o

Over a year ago our company went through a merger.
Somehow one of the developers/team leaders got a principal engineers role during the transition between the old and new company. He team lead one person in his previous role!!

I got put on a project with him and the other guy.
They're both pretty bad but at least the other guy is just a standard developer.

I'm having daily calls with these two guys and explaining basic coding principals.
This "principal" engineer apparently has 20 years of development experience but is relatively new to c# ie. 2 years!!

Disregarding being new to c# someone which 20 years experience should at least be able to get logic correct. So how does someone like this write code like this:

Seriously writing a method to compare two strings which is only used once and inside a simple if condition. Nevermind the false == or the empty brackets.

    public IsMatch(string var1, string var2)
    {
        if(var1 == var2)
            return true;
        
        return false;
    }

    if(false == IsMatch(Str1, Str2))
    {;}
    {
        // bleh bleh some code. 

    }    

or another instance where he has 15 nested IF conditions.
If i ever saw this guys pay packet id probably go on a murder spree.

BrokenArrows wrote: »

    if(false == IsMatch(Str1, Str2)) 

There is a small argument that because

bool x = true;
if(x = false)
{
}

is valid, that putting false first is less error prone. It's a very small argument and it should be shortcut anyway, but it exists

FobleAsNuck wrote: »

in your example x will always be false

I believe that's his point. You couldn't make that mistake if you said

if(false = x)
{
}

because 'twould be a compilation error.

Raging_Ninja wrote: »

Came across this insanity earlier on StackOverflow:

http://stackoverflow.com/questions/33996777/task-scheduler-doesnt-work-when-select-run-whether-user-is-logged-in-or-not



And in response to my prodding:

Seriously though.......

ED E wrote: »

SO users should have to pass "purgatory" of 1000 rep in SU before being allowed to post....

Much like here, there is an ethos on SO that you have tried the most rudimentary solutions or at least make some effort before posting. One wold think that having the machine turned on would be fall into the former category there.

c_man wrote: »

Ah I dunno, I think the rep situation on SO is... lacking. How many times do you find yourself being downvoted for no good/explained reason?

I (foolishly perhaps) gave an answer to a question which was a little vague recently. After some back and fro with the submitter on the comments to my answer, he updated the original question. Now my answer looked very much out of date and got a heft of downvotes. /disgruntled

Yeah, its very easy to get down voted, I was close to getting banned from posting at one stage in the early days, Took a while, but i've built up a decent enough rep there.

Itzy wrote: »

Can't say I've ever heard of Companies preventing "Developers" from doing their jobs, unless they were Support Engineers, given the title of Software Developer.

It does happen in bigger companies. And companies that aren't "software" companies, but who do some in-house programming - they try to develop programming practices based on the legal or regulatory guidelines for their non-software business, and come up with bizarre processes. Banks are notorious for it.

Role drift can also play a big part. So in the above example, imagine that a company notices that 25% of QA time is being wasted because code can't run/compile and so the QAs are just batting these things straight back to the developers instead of actually doing some testing.
Someone suggests code reviews - no commits unless its reviewed by another dev. Hurray!

Six months later, they notice 30% of dev time is spent reviewing, the backlog is growing, and the problem is cumulative.

They throw more devs into the mix, hurray.

But then someone notices that payroll has increased by 30% even though the code throughput hasn't. Hang on, why are we paying expensive developers to do nothing but read code instead of writing it? Let's hire graduate developers instead, they can review the code. Woohoo.

Three years later they've a problem; their grads only stay 3 months on average, and any that do get moved up the ranks are pretty poor coders and know very little about the systems they've been working on. Oh, I see, developers aren't interested in doing nothing but reviewing and committing code. Well, what if we hire data entry clerks? They can be told how to edit the files and compile it, and be given a process to follow if it doesn't. Hurray!

Two more years pass, the technology is becoming more varied and complex and the maintenance overhead of making sure the data entry clerks have the correct IDEs and compiler versions is nearly beyond control. What if we just have the developers compile their code locally to make sure it works and then send the amendments onto the data entry clerks? Genius!

And so, ten years after the original process was put in place, the process remains in place more-or-less but the entire point of the process has been lost.

In very large companies inertia is a big problem with these processes - a new person says, "Hey, what if we just have an automated testing environment that does basic compile and exception checks before moving to QA?", and the response is, "Great idea. Just fill out a process change request form and schedule a summary meeting with your team lead, who will then set up a forwarding meeting with the section manager. If he likes it, he'll discuss it at the monthly regional technology leadership meeting, who will schedule it with the CTO at a quarterly meeting. Though the agenda for these meetings fills up quickly, so it may be 6 months before the CTO has a chance to properly look at it. And we can't change the process without CTO sign-off. Once the CTO has signed off on it, the legal team will have to review it to make sure it's OK and then it'll be passed to the IT department's change process to ensure that it's implemented properly. Once that's done, it goes to the training guys who'll need 3 months to develop a staff training programme and a further 3 months to roll out the new process before it goes live".

---

Interestingly enough, the Hawthorne effect suggests that a programmer's code is more likely to be error-free when they know it's going to be reviewed, so there may be some benefit to have a non-programmer "review" code before committing. Bit wasteful though.

One suggestion in the last place I was in was a script which matched the production logs against the Git commit database and produced a scoreboard which showed whose code was generating the most errors in production. It was originally built to try and find the "owner" of a piece of broken code, but then the potential was realised.

Unfortunately it was scuppered and the scoreboard, affectionately known as "Wanker of the Week", was permanently mothballed.

I'm in a 3 man development team and I asked the Senior Developer (SD) why we don't have any strategy for working on projects.
SD says, something along the lines of:
In the real world there is no time to plan projects, you just have to do stuff as you go along.

The only way the SD tackles projects is by simply going to 1 meeting to get some specifications from the user and then cracking away writing code.

And here's me wondering why there is no source control, no project plan, no documentation, no best practices, no software patterns used...
The SD is adamant on writing everything in one class. If the SD sees more than 2-3 classes in a library you need to rewrite.


We have an email group for error messages.
I redirect those into a sub folder.
It has about 7.5k emails after 6 months or so.
When I questioned the SD about these, the SD said that i'll get used to seeing the ones that are actually bad errors

I checked one of the server's event viewer.
About 4k error entries in there.

There is possibly new management rolling in, so I'm sure they'd spot and sort this madness.
Gladly the other Developer is on the same page as me, so there seems to be a bit of hope.

[Rasta] wrote: »

I'm in a 3 man development team and I asked the Senior Developer (SD) why we don't have any strategy for working on projects.
SD says, something along the lines of:
In the real world there is no time to plan projects, you just have to do stuff as you go along.

The only way the SD tackles projects is by simply going to 1 meeting to get some specifications from the user and then cracking away writing code.

And here's me wondering why there is no source control, no project plan, no documentation, no best practices, no software patterns used...
The SD is adamant on writing everything in one class. If the SD sees more than 2-3 classes in a library you need to rewrite.


We have an email group for error messages.
I redirect those into a sub folder.
It has about 7.5k emails after 6 months or so.
When I questioned the SD about these, the SD said that i'll get used to seeing the ones that are actually bad errors

I checked one of the server's event viewer.
About 4k error entries in there.

There is possibly new management rolling in, so I'm sure they'd spot and sort this madness.
Gladly the other Developer is on the same page as me, so there seems to be a bit of hope.

I work in a one-man development team in an academic environment - I've never actually worked with other developers.

But, even I know that all of the above is appallingly bad practice.

Get out.

Now.

Maximus Alexander wrote: »

I'm in a unique situation on this thread where the person I hate is my former self.

Ermm, no. Your're not. I've had the same problems when I look back at code I wrote in the early days. I even have some change requests for a project that I wrote 18 months ago and some of the code in it is a cringe fest.