We live in a world that changes everyday and software is one of the biggest part of that change. People interact with software in many ways, such a...
For further actions, you may consider blocking this person and/or reporting abuse
Having been a developer for 30+ years I find it fascinating how schools can expel new developers who can't read and maintain existing code. Careers in literature require a lot of reading and understanding of the language before the first new literary work is created - let alone published. Science requires a lot of procedure following behind those who have come before. Software development seems to forego all of this and instead says "read the dictionary then write me a novel". Too many coders can only build new things from scratch and have a very difficult time maintaining existing (many times legacy) code. This skill would help in points 4 and 5 of the article. Remember that not all code has the privilege of being created in the newest, best, cleanest environment.
This maybe because everyone gets Computer Science degrees instead of Software Engineering degrees. People mistakenly think the two are the same, and come out of university with their fansci compsci degree without knowing what Bash, git, or TCP/IP are.
I think it depends on the program, and not necessarily just the degree. My CompSci degree included a pretty in depth focus on Bash, git, TCP/IP and actual practical skills. But, I've seen other schools that are way too theoretical. ¯_(ツ)_/¯
Makes sense! Where did you get your degree if you don't mind me asking? It sounds like your school did it right!
Don't mind at all :) McGill University -- in Montreal. But I've definitely taken classes at other schools where there was no emphasis on actually coding as well -- which is...worrying :/ [Edit: Just realized you're IN Montreal! Awesome!]
Oh nice, I'm in Montreal too. I've heard good things about parts of McGill's compsci program.
I purposefully avoided any practical lecture in university. Even now, after deciding on a career in Software engineering, I do not regret that decision. The reasoning and problem solving skills I developed are much more valuable to me in my day-to-day work than knowing about some specific technology could ever be.
To me this "find the best solution and not a solution" sounds rather crazy. You'll spend your days trying to figure out the best way to do things, instead of actually accomplishing things.
You'll end up in a situation like this
Of course you should not just rush into things and do the first thing you can think of, but wasting your time looking for that mystical "best solution" is crazy. Iterative development is generally the best way to do things: Create a "good enough" solution, that has been developed based with some thinking, and then if there are issues with it later fix them then.
When you set up your own business you will soon realize you can't just sit in a dark room forever implementing your "best solution" and do need customers to use your "slightly less than perfect solution" to get money in, and to get real feedback from. The assumptions you make about a "best solution" without any real user feedback are simply going to be wrong and are going to lead you down a path of a lot of wasted time and money.
I thought exactly the same thing.
A wise man once said: "We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%"
But first, we have to know which 3% and chances are really, really, really good that it's NOT the little chunk you're hung up on trying to find "the best" solution to/for.
Paralysis by analysis is a real thing and slows everything down while the "loop-ee" doesn't even realize they're executing an O(∞) search algorithm.
Indeed.
There are certainly cases where I can say "this is a critical path that I should spend some time optimizing more", or "this part is going to have to cope with a lot of different situations and I should think about it in advance", but in most cases "hey this works" prevails.
Sometimes a day, a week or a few months later I see "oh, didn't expect this to happen, now I guess it needs some refactoring", but that's a lot better than having delayed everything else I worked on by trying to predict the future and accomplishing nothing.
Interesting article except from your test percentage claims, they feel a little hand-wavey
Kalispera! I would agree with you that when you have a lot to do, these numbers may seem unrealistic. It's a common thing and there is no issue with it. There are two things to keep in mind though:
a) 100% code coverage is an asymptote and a number to keep you a bit mindful on your tests. You can never reach that number, but you can be somewhere close to it. For example, recent project I was working on had 83.7% and we were happy with it.
b) Even if you think that you are too busy to write your tests, you have to remember the most basic law in TDD, which is that you have to write the minimum amount of code to make the test pass. That's why TDD reduces bug density and development effort.
Also remember that TDD and testing in general is a discipline and you get better and better with it over time. Happy coding my friend!
Thanks for sharing this Stelios. It helps alot in our area of software development.
Have you seen Uncle Bob's talk on this? m.youtube.com/watch?v=Tng6Fox8EfI
Good article; very enthusiastic and encouraging. You don't see much with those qualities written these days.
Nice article!