4 ms·
Oh man, I wish I had this at my last job half the team had over 50% of these symptoms, one guy had 90%. They believed, and had somehow convinced management, tha
by sophacles 17y ago
Oh man, I wish I had this at my last job half the team had over 50% of these symptoms, one guy had 90%. They believed, and had somehow convinced management, that they were great programmers! Some awesome practical examples from those guys below:
Overheard statement "You know when I was in college I learned C. I just can't get the hang of these objects, so I try to avoid them". The guy who said this is now 34, and has programmed python for 4 years.
A guy who would copy and paste 100 line blocks of code, and then occasionally thing "oh yeah, i need functions", and then finish out the current function by passing 12 parameters of state to current_function_2(). If you combined the func, func_2 and factored out the 100 line blocks it would be reverted with a commit: "stop making this so complicated".
There was one guy who insisted that using templates was only for web frameworks, to use them to write system/config files (done frequently due to 3rd party daemon limitations) was an abuse of the templating system, and we should just use inline prints. The program was to be called with prog > /etc/conffile.
One guy who decided that threads were so tricky, that he was the arbiter of thier use. My idea of a job queue and worker threads was "too abstract and hard to debug", so we stuck with the "tried and true" one thread per job method, all spawned at once.
I could go on, but you're all prolly bored now :)
tl;dr: i worked with the guys the article was written about
- jacquesm 17y agoouch... I love the 'stop making this so complicated bit'. While some people really don't get it I'm pretty sure that most people could learn how to program with some competence. The only metric I've found to measure programmer competence reliably is how big a project you can manage to complete. Some people get stuck at around 100 lines, others in the thousands or tens of thousands, some can keep their rudder straight across 100's of thousands of lines. The latter takes extreme self discipline and organization.
- blasdel 17y agoLOC is a horrible metric for this, given the degree to which morons can get comfortable with copy-paste and IDE-generated boilerplate. Gzip-bytes of source FTW.
- jacquesm 17y agoGood point, I hadn't thought of the ease with which text can be copied and how much garbage an IDE will spit out. Thanks! Clever trick to measure the real information content of code using gzip too.
- nostrademons 17y ago"you can manage to complete" Implicit in the notion of completing a project is the certainty that the project manager will change their mind, usually after you have written 95% of it. If you copied & pasted those hundred thousand lines, you will have to change something in at least 100 different places. At that point, you'll give up in despair, proclaim the change impossible, and have the PM cancel the project in a fit of frustration. Thus, not complete. LOC actually sorta makes sense in this context.
- haberman 17y agoI disagree; what takes extreme self discipline and organization is doing in 3,000 lines of code what a less organized developer would have done in 15,000. Code is a liability; developers who can get to the point save you in complexity and maintainability.
- berntb 17y ago>>I'm pretty sure that most people could learn how to program with some competence. That is what logic tells you, but I've seen smarter people than me, which couldn't get it even after years of trying. (I helped a few with labs while studying.) You shouldn't have too much grit. You characterization about handling program size fits well with my own development. Interesting point.
- Dove 17y agoA good method. The skills required to create or navigate a codebase of 100, 5000, or 100,000 lines are different not only in degree but in kind. Behaviors optimal in the first case can be brutally maladaptive in the last, and vice versa. A preference for global variables or multi-threaded solutions says a lot about the size of project one is comfortable with. But beyond the practical, what you're really measuring is the ability to break down a large problem, solve individual pieces, reason about how those interact, and iterate. That is the critical intellectual muscle that makes programmers reliably great. I remember a few projects I abandoned when their size outgrew my ability to comprehend them. It took multiple attempts with new methods to break through certain complexity barriers. I could not write a program longer than about 500 lines until I had learned the practical use of subroutines and data structures. I could not write a program longer than a few thousand lines without a sense of taste when it came to objects and modules. And I could not write a program of significant size until I reliably turned out code that could be comprehended at a glance after months or weeks away, as my own throughput guaranteed it might be that long between visits to disparate parts of the codebase.
- jacquesm 17y agoHah! I remember that... I was still a kid, I really wanted to write a music composition program. One attempt after the other, this giant, monolithic piece of spaghetti. I just could not be done. Around the 700 or 800 line mark I lost overview and it would grind to a halt forever more subtle bugs to fix. This went on for weeks, maybe even months. Then a friend told me the magic words: "structured programming". I went to the library and read a book (I forgot the title, I think it was by Wirth). Within 3 days I had it up and running.
- run4yourlives 17y agoI'm 34. What the hell college was he going to that taught C exclusively in the mid 90s? Perhaps he was taught C++ and just didn't understand half his courses? :-)
- jff 17y agoProbably a good one, if they taught C rather than C++. (flame-retardant-underwear-mode t)
- swwu 17y agoWell, I only have experience with one college, but Stanford offers an introductory-level class in pure C and x86 assembler.
- run4yourlives 17y agoKey word being exclusive.