Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
Search - "alternative truth"
-
5 Types Of Programmers
1.The duct tape programmer
The code may not be pretty, but damnit, it works!
This guy is the foundation of your company. When something goes wrong he will fix it fast and in a way that won’t break again. Of course he doesn’t care about how it looks, ease of use, or any of those other trivial concerns, but he will make it happen, without a bunch of talk or time-wasting nonsense. The best way to use this person is to point at a problem and walk away.
2.The OCD perfectionist programmer
You want to do what to my code?
This guy doesn’t care about your deadlines or budgets, those are insignificant when compared to the art form that is programming. When you do finally receive the finished product you will have no option but submit to the stunning glory and radiant beauty of perfectly formatted, no, perfectly beautiful code, that is so efficient that anything you would want to do to it would do nothing but defame a masterpiece. He is the only one qualified to work on his code.
3.The anti-programming programmer
I’m a programmer, damnit. I don’t write code.
His world has one simple truth; writing code is bad. If you have to write something then you’re doing it wrong. Someone else has already done the work so just use their code. He will tell you how much faster this development practice is, even though he takes as long or longer than the other programmers. But when you get the project it will only be 20 lines of actual code and will be very easy to read. It may not be very fast, efficient, or forward-compatible, but it will be done with the least effort required.
4.The half-assed programmer
What do you want? It works doesn’t it?
The guy who couldn’t care less about quality, that’s someone elses job. He accomplishes the tasks that he’s asked to do, quickly. You may not like his work, the other programmers hate it, but management and the clients love it. As much pain as he will cause you in the future, he is single-handedly keeping your deadlines so you can’t scoff at it (no matter how much you want to).
5.The theoretical programmer
Well, that’s a possibility, but in practice this might be a better alternative.
This guy is more interested the options than what should be done. He will spend 80% of his time staring blankly at his computer thinking up ways to accomplish a task, 15% of his time complaining about unreasonable deadlines, 4% of his time refining the options, and 1% of his time writing code. When you receive the final work it will always be accompanied by the phrase “if I had more time I could have done this the right way”.
What type of programmer are you?
Source: www.stevebenner.com16 -
Disclaimer: I apologise in advance for those tired of language wars, if it bugs you that much just skip this rant.
"C++ is better than C"
An accepted truth. OO is better than Procedural, C++ is an upgrade from C, it fixed all the problems.
End of.
Except - when it comes to actual evidence, empirical studies have shown that there are no productivity gains with C++ vs C.
This bugs me the most because it's such a fringe view, OO has dominated industry purely by dogma, alternative programming paradigms are just simply ignored because: "OO is best. End of."
https://researchgate.net/profile/...22 -
Does anyone else find it strange that the stupidest people in the company are making all the decisions.
In order to be able to engineer software you have to understand everything that the product owner knows, the business analyst knows, the product manager knows + how to actually make the system both work in a reasonable time frame and be maintainable long-term.
But we're not the one making the decisions. The irony of it is something that I can't get beyond.
And when I do go out on a limb to point out a logical inconsistency to UX or product... They don't thank me for it they hate me for it and then 3 days later figure out that they should be doing it and quietly follow my suggestions.
Seriously is the goal here to create good software or to avoid stepping on everyone else's toes in the company who is overwhelmed by the complexity of the project.
I think companies based on a hierarchy of non-technical people controlling technical people, in the creation of software products are a dying breed.
When it comes to creating software products everyone in the hierarchy should be technically minded.
I've seriously been trying to come up with an alternative perspective here.
The executives of the company are completely out of touch and the only thing which looks like progress to them in a sprint review is something visual on the front end.
The technical architect, the product owner and the product manager all seem to be engaged in keeping the executives happy and managing their expectations. By means of obscuring the truth.
Imagine how much more cost-effective building a software product would be if the executives were engineers themselves.
I'm keen to do an experiment and build a company comprised of engineers only.
Obviously they need to have insight into the other roles. But none of these other roles are as complex as implementation itself.
So why exactly are we the slaves of these well-meaning under thinkers?7