- Feature Articles
- CodeSOD
- Error'd
- Forums
-
Other Articles
- Random Article
- Other Series
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
TRWTF is getting on your soapbox on a feed I subscribe to for WTF's.
Admin
great, I also try to simplify my code greatly, a few years ago a read about 'clean code', adopted the guidelines and this aided me greatly.
Admin
I don't think I can point at any one teacher as the best one ever. However I learned the simplicity rule myself from life experience. It's similar to other rules I try to follow: don't force children to do something, explain why they need to do it for their own good. Be able to explain complex topics in layman terms. It's so frustrating when people try to describe certain topics using heavy industry jargon.
Admin
If writing simple code - and reading other people's - has taught me anything, it's that any time someone sticks hard and fast to such rules as "one entry, one exit" or "never write a procedure longer than a screen", they tend to complicate their code in order to make it comply with their laws, rather than let them be guidelines that help simplify it.
Admin
My first boss, and most important mentor, was... "a man of few words".
Do something right? He wouldn't even acknowledge your presence. Do something improvable? He'd just ask you if you were drunk and walk away. Sounds like a jerk, but I later found out that he reviewed every single line of code I ever wrote and only intervened when I could do something better. And if you were stuck, he was always there to help you without ever holding your hand.
He taught me that quality should be expected, and thus not praised, and that I should learn to only rely on my team when I really need their help, not when I want it.
Admin
On the other hand, all too often I've seen code that is spread out through dozens-upon-dozens of 3-line methods and HelperFactories when it could easily have fitted onto one to three screens. That's the other extreme that hurts readability.
Admin
Ref snoofle's Math prof ... Here is a website that focuses on the same approach to math: "explain the concepts and motivations in simple concrete terms so the formulaic details appear automatic and obviously necessary" (my overcomplex words, not his) https://betterexplained.com/
A bunch of what he teaches is the kind of math most engineering or CS grads take for granted. But we all have weak areas and can probably pick up an insight or two. And no I'm not affiliated with the site.
Admin
There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult. It demands the same skill, devotion, insight, and even inspiration as the discovery of the simple physical laws which underlie the complex phenomena of nature. -- C.A.R Hoare
Admin
Not so much a teacher, but a course: the first CS course I ever took in college was based on a C-like pseudocode rather than any real-world language. Assignments were hand-written and hand-graded; there was no compiler except the one between your ears. Thus, the focus of the class was on concepts and fundamentals of programming in general, logically thinking through your code rather than scratching out something that will pass an automated test in the language du jour. I think I learned more about software development in that one class than I did in the rest of my time at the school.
I was sorely disappointed when I learned that the school changed out that class a few years later for one based on Scheme or something.
Admin
Short procedures (that cannot extend past a single screen) are the kind of guidelines that are a poor substitute to common sense. It's like that vertical line in many IDE at 80 characters, which is supposed to remind you to write short lines. What happens is that people use continuation sequences and simply split their long lines in two, which follows the letter but not the spirit of the guideline. Same for short methods; people end up replacing their switch or if statements with separate methods just to bring down the individual LOC count. Of course the separate methods are often logically dependent on each other and can't be reused, so they only make the codebase more brittle and require more unit tests (because "coverage" - another mindless guideline).
As the saying goes, advice is just recycled experience that someone tries to dump on someone else. No thanks. There's already a decent corpus of design patterns and best practices out there that are well documented and justified, nobody needs folksy rituals acquired in the trenches of a world that no longer exists. Also this is a site for WTF not for strolls down memory lane that are relevant only to the editor.
Admin
As I walked into the first day of my grade 11 chemistry teacher told me, remember all that stuff you learned in chemistry last year about Bohr Rutherford, etc.? - well it isn't true! And the stuff you learn in this class this year probably isn't true either! What you will learn is the best theory that we have not to explain how things work at a molecular and atomic level, a better theory will probably come out and replace it in the future!
What this taught me is, never assume that what you know today is carved in stone and the ultimate truth, be open to the possibilities of other better ideas in the future.
Admin
By the time a man thinks his father was right he usually has a son who thinks he is wrong.
Admin
This story resonates with me as I'm preparing for my final in Probability & Stats tomorrow. I truly wished I'd had a mentor that had made the subject as clear as I know it can be.
As for code, yes, over the years, I've had some very good mentors. In particular, one gentleman (with whom it was my privilege to work), picked up a book on regular languages and implemented an XML parsing engine in UEFI just so he could actually get to the real project. Another gentleman helped guide me into good coding practices by simple statements such as, "Classes should be nouns and the member functions verbs." He also, indirectly, introduced me to the concept of, "take some time to plan before you start banging out code." Then, let's not forget the general maxim of UNIX, "Do one thing, and do it well." (Sadly, deviation from this maxim occurs all to often.)
In short, any idiot can take something, anything, and make it complex: genius can make something complex, simple.
Admin
I learned the importance of simplicity when teaching system admins from around the world in the late 90s. The non-native English speakers liked that I spoke slower, used fewer idioms, and gave clear instructions on how to complete the exercises. Sadly, some of the native English speakers complained I spoke too slowly.
Admin
I simply could not read past "cow-orker". Oh well, off to write some complicated code....
Admin
It's one thing to agree that you haven't really mastered something until you can explain it to someone who doesn't know it.
How you get from that to not caring about deadlines is beyond me.
Admin
It is Teacher Appreciation Week, and I think this is kind of nice.
Admin
"classes should generally do one logical thing"
Classes don't DO anything. Static methods may, and objects may, but classes aren't even instantiated...
(and how many objects in reality do you know that do one thing? zero - there are multiple properties and methods to everything)
Admin
The fundamental rule of Statistics is "Knowledge Is Power." That is, you only need stats because we don't/can't have complete knowledge of the system.
There are lots of corollaries, such as "Don't use p=values unless you truly understand what they imply," and "Anyone who tells you the sample size depends on the population size needs to be permanently barred from doing Statistics."
And, of course, the Most Important Rule: when Monty Hall asks if you want to switch, always switch!
Admin
I had a computer science instructor who gave a lecture about thinking inside the right box. He drew a square on the whiteboard and said this is the box you might get caught inside. The whiteboard represents what is possible. Think outside the square, but remember there are practical limitations to what can be done like time, budget, and technological limitations.
I suppose he said there are people who can expand the boundaries of the whiteboard, but that was outside the scope for that particular lecture.
Admin
Every one of us has had a "moment" that changed how we look at code. My "moment" was reading the Refactoring book. Snoofle's was this class. If you haven't had one of these moments yet, come back to this story in a few years when you have had it.
I think it is important to be reminded occasionally that our craft really does matter. It's not enough to avoid writing "WTF"s; it is important to do excellent work.
Admin
Is it The Master Is Simplicity, or The Master Is IN Simplicity? You wrote both. Also, it's "for whoever came after me", not "whomever"; it takes the case of the noun in the subordinate clause.
Admin
That kind of class would drive me nuts. I have a mental condition called aphantasia, which prevents me from having "a mind's eye". I can neither recall images, or create images. This condition affects only 2% of the population, which means the other 98% can't even comprehend why "well, everyone has a mind's eye" is false.
Admin
This reminds me of the Feynman Technique for learning: https://curiosity.com/topics/learn-anything-in-four-steps-with-the-feynman-technique-curiosity/
Admin
The teacher I feel taught me the most important meta-lesson was my CS professor who clearly, visibly considered every word to come out of his mouth. That care led to a fluency and precision of speech I have yet to hear from anyone else and impressed me greatly.
Admin
+1 for the Monty Hall Paradox reference. I've had so many fun arguments about that one... strangely enough, mostly with Engineers who believe your odds are 50/50.
Admin
Well, that's swell that you had a professor in favor of simplicity. Howsumever by the look of most of the code out there, for every pro-simplicity professor, there are a gross-gross professors and teaching associates that suggest that a simple "print an error message" function should be hidden about 18 levels deep in classes and methods and interfaces and similar crap. Yep, not long ago I had to work on such a monstrosity. Never did figure out where the error messages were being triggered from-- the debugger would not trace back that far.
Admin
Monty Hall problem depends very, very strongly on the exact description of the problem. Lots of people read about it, read the solution, but when they pose the problem to others, they modify it just slightly so that the solution they read isn't right anymore
Admin
"For whomever should follow" is correct; whom is used in conjunction with prepositions (to whom, by whom, for whom, through whom, etc). Use who if there isn't a preposition (who let the dogs out? who is your daddy?)
Admin
Yes, because like all problems of that type, it's actually a word game. The object is to disguise a simple problem in such a way that you appear to be asking something quite different. There is no mathematical or logical cleverness required to solve such problems once you unravel the wording.
That's why so many clever people have been confused by the Monty Hall problem and mistakenly concluded there are three boxes involved, rather than two, and then come up with the kind of answer such a problem implies it deserves. Phrased more clearly, it's obvious the third box is a red herring, and the problem is trivial. It's just a childish trick question.
Admin
Sadly common sense is one of those things in very short supply, and that is why there are guidelines like "Don't make your lines of code too long because you can't get 2 lines like that on a diff on even a wide screen" and "don't make your functions too long because your brain will have forgotten what's at the top by the time it gets to the bottom" (and it's fracking annoying have to repeatedly scroll up to see what the parameters were)
And code coverage - well, yes, that can be abused. Not only should you aim for high code coverage, you should not call a function just to get coverage. 100% code coverage isn't a proof you have a good unit test. But 90% code coverage is proof you have edge cases you can't be sure will behave in the same way as they used to when you fix a bug or refactor the code.
And it's those untested places that cause 90% of the problems in production.
The world you feel no longer exists is alive and kicking.
Admin
Not so. Look at the sections on free relative clauses here for example (https://en.wikipedia.org/wiki/Who_(pronoun)). "Modern guides to English usage say that the relative pronoun should take the case appropriate to [the] internal clause, not the function performed by that clause within an external clause." Another good suggestion, no charge, is that if you're going to use "whom[ever]" you should be damn sure you know it's correct.
Admin
My first software engineering lecturer pronounced it "computOR". I don't think it got significantly better from there.
Thankfully I've had many years to learn these sorts of principles the hard way... or at least the long way.
Admin
It's in Editor's Soapbox, what do you expect?
Admin
The worst code is written by those who think they are smarter than anyone else. I have been writing code for over thirty years. Without fail, the code written by 'genius s' is atrocious. That is the gold mine of WTFs
Admin
Then there is the "interview question" that you really should ask any would be programmer: Write a routine that takes as input "1 or 2" and returns the other. Use any language you want.
Some of the answers you get can show sheer stupidity and less knowledge of general programming.
Yes, the answer can be simple, but it is all in how you phrase the answer that makes a difference.
Admin
The SoaoBox has been a category on the site for probably longer than you've been a member.
Back at the start (I forget when I first started browsing TDWTF but I remember I found out about it on live journal back when that was young so that should give you some indication of how long ago that was) There were no categories like there are now, they came in when the site was redesigned (the first time) which I think was 2009/10? That's when the soapbox first appeared.
So you're complaining about something that has been a feature of the site for around a decade... If your not used to it by now then you sir are TRWTF.
Admin
"This time, the professor was a crotchety old German mathematician."
why did my brain immediately go to the thought and idea that "yeah, I bet observing concentration camps can be a good way to learn probability and statistics".
??? =D
Admin
...yeah, the thought was real, but me saying it out loud was supposed to be just a rude joke, but as I continued on reading, I almost immediately regretted I wrote it.
"The man was truly a master of his craft; arguably one of the very best teachers I ever had in my life. Unfortunately, they forced him to retire the following semester. Unable to teach, he was bored, lost his passion and died shortly thereafter. "
he sounds like he was an amazing guy.
Admin
I had two teachers that I think had profound effect on me, even though it was when I was younger, so I didn't have the ability to properly analyze and percieve it when it happened.
Both were at my high school. One was a programming teacher, guy barely 6 years younger than me, was working as IT admin of our school, and was teaching on the side. He was the precise opposite of all the nerdy programmer tropes, except the one about being nerdy and knowing absurd amount of relevant (up to barely-relevant, but still fascinating) information about most of situations and topics. Otherwise, he was one of the most gregarious, outgoing, funny and lively people I've ever met. And extremely intelligent. And very friendly and humanlike. It was fascinating to watch and listen to him talk, in general, whatever it was he was just talking about.
The second one... okay, maybe I had three, but the third one is a special case... So the second one was my physics teacher at that school. She was a hurricane, kind of, with a temperament of what I imagine female Goebels would be, if he were 20 years older (she was around 65), so as a bonus he learned to not concern himself with petty unimportant crap. So the first lesson I ever had with her started with her barging energically into the classrom, and started talking right after she went through the door:
"Let's make one thing clear: if you wanna drink, take a drink, don't raise your hand and ask me if you can, we're not a prison. If you're hungry, just eat, we're here to teach you, not starve you. If you need to go to toilet, just go. All of those things, if you just do them, will distract me and you and the rest of the class about hundred times less than if you were to ask. So just behave like people and everything's going to be fine".
While she was teaching me, it was the first time in my life when I, at the same time:
Admin
Her lectures, explanations, answers, were like a tornado that sweeps you up, bashes you into all the facts and principles that go into understanding the concepts, let you fly around in between them, to enjoy the "OHHHH! I UNDERSTAND COMPLETELY NOW!!!" feeling, then dropped you off with a smile, and left you to your own devices to inspect all your (proverbial) bruises and piece from them the boring theory.
Which is what I was bad at, the "boring theory", the calculations, which is why I was getting such bad grades. Partially, i had the bad "habit" of making tiny mistakes which then rippled out through the calculations and led me to slightly (up to completely) wrong results. Partially I didn't have enough discipline to sit down and train those. But the principles, oh, the sweet principles of it all!
Also, she was one of the small number of teachers able to process when I got to the right result by some completely different way than what's normal, and was able to understand and appreciate my way of thinking.
Then, the third, special case, was my other physics teacher in that school, which I transferred to when the awesome one above warned me that she likes me and will be sad to see me leave from her advanced course, but she thinks due to the type of my issues, it's just going to needlessly sink me, so I should switch.
Admin
So I did. Which led me to the third "special" teacher. This teacher was the one that yelled at me for wasting 10 minutes of her lecture because I was trying to explain to her she switched the wavelength/color(-frequency) axis. That correctly, INFRAred is supposed to be on the left, because it has the longest wavelength (and thus smallest frequency), and ULTRAviolet is supposed to be on the right, because it has highest frequency (and thus shortest wavelength). She didn't understand. It took 10 minutes to explain to her what I even mean.
Another funny time was when I started to properly realize the 3D shapes of magnetic fields, so I asked her "oh, so the fields are 3d, so when I do the iron filings experiment with a live wire... if I lay the wire flat on the paper, I would get filing lines perpendicular to it, and if I punched the wire through the paper, so it goes perpendicular through the paper, the filings would line up in a concentric circle around it, right?"
She looked at me completely confused, and after about half a minute of silence she responded: "What? No... You... that won't work, you can't do that."
"...you mean... I can't take a wire, punch it through a paper, spread the filings on it, and then connect it to a circuit?"
"Yeah, no, you can't do that."
...yes, that was the actual exchange. But at that time, I was asking her purely out of curiosity about her answer, I knew whatever it's going to be, it's not going to be anything useful. So then I immediately went to ask the previous physics teacher, and after about half a second of me finishing my question, she said: "Yeah, of course."
Now I realize I'm not sure whether that would ACTUALLY happen in an actual experiment, but at least she correctly parsed out the point of my question (checking how would two different cross-sections of a magnetic field look, so I can piece together/validate how I think the field actually looks in 3D) and was able to answer it.
Admin
I've been following this site since way before that redesign you mention, so dude, dial down on the old timer entitlement. The soapbox articles have been boring since the beginning, and the fact that they have existed for so long doesn't make them any better (same goes for cancer or Nickelback). In fact even the sponsored articles are more interesting.
If you want to see how much people love articles about best practices, why don't you start a website called "thedailysoapbox: stories from retirees who volunteer in local schools tech support and tell us how many lines a function should contain" and see how much traffic it generates.
Admin
I would subscribe to that.
Admin
What more do I need than return "the other"; ?
Admin
Bye snoofle - we'll miss you
Admin
Ah, yes, I have -- and in a non-technical field, no less: journalism.
I had a professor who told us that if anything you say or write is misunderstood, then you didn't say or write it correctly.
Now, of course, there's exceptions to that, but as a rule of thumb it holds in so many cases.
Admin
The vertical line is there because
Screens, sheets of paper etc. are not infinitely wide, so there is a physical limit to how long a physical line of code can be.
Long lines of text are difficult to read for humans.
Limiting the width allows you to put two or more pieces of code side by side, which is especially convenient for diffing and merging.
Terminals are traditionally 80 characters wide, so it's convenient to choose 80 characters.
Admin
"I always made sure that what and why were graphically documented (in both class- and block-level comments) "
You put images in your comments?
Admin
I use the same principle in all things financial: If you cannot explain a financial construct (bookkeeping, shares, funds, ...) in simple terms, something is missing or suspect.