I never really got programming either. Did a Pascal evening course for a while, sort of understood things but when it came to writing my own bits I quickly got out of my depth. A few months later I got my first job which was as a VAX/VMS operator/Powerhouse programmer. I was fine at the ops stuff just crap at the Powerhouse 4GL programming. My next IT job was a Wintel consultant and I've never looked back (that was 18 years ago), although I'm now trying to avoid powershell scripting...
Well, I wrote a computer teaching program for Strathclyde Region primary schools, to teach children basic maths, spelling and grammar. On the BBC Micro. When I was at primary school.
So there 😀
One of the things I like with my embedded work is that I can point out something in a shop and say "I made that".
that's pretty much my philosophy, except in my case it'll be "see that barely visible bright white dot zooming across the night sky" (except for the one that is 45 light minutes away, where you'll just have to see it every time it's on sky at night).
I hire engineers based on an 'are they smart and do they get stuff done?' policy. You lot fail the latter because you just spent the whole working day having a p***ing contest over tools and methodology.
+1. I had a team member recently (who left a couple of months ago) who whilst technically adept, always became obsessed with the minutiae of writing perfect code. He'd spend hours obsessing about non-important issues when he'd already solved the problem. It had me tearing my hair out on numerous occasions.
whilst technically adept, always became obsessed with the minutiae of writing perfect code
Did he ride a Turner by any chance?
Did he ride a Turner by any chance?
well it wouldn't be me - look back at my reasoning for TDD and the fact that it helps you meet you release goals without necessarily having perfect code.
If something has to be coded up in a non-optimal way to meet the deliverable then it doesn't matter - the importance is that the test works.Once delivered you then refactor to make the code better, before you build on it again - otherwise the entropy of the system will increase.
If a code review at the end pointed out that you had done it the wrong way or that the code was iffy, then so what? Any code review is at the start of the next phase, probably with your pair as you design it.
If I am writing code that will be in a multithreaded/asynch environment I will stress a bit more about the code being right - it is still pretty hard to properly test such code so you will be doing you best to write it correctly in the first place.
Did he ride a Turner by any chance?
😀 Get over it mol.
The aptitude test he posted had two very obvious bugs in it that would definitely cause issues in the software.
Spotting that is really not being [i]"obsessed with the minutiae of writing perfect code"[/i] - it's just producing code that works correctly.
Sadly too many "JFDI" managers would be happy to accept that code because it appears to work and would pass a naive unit test with 100% code coverage.
Get over it mol.
I'm just having a laugh...
I think I've worked it out - molgrips is working for United Airlines ?
http://money.cnn.com/2015/07/08/news/companies/united-flights-grounded-computer/
😆
