Code is art and every artist wants to go back and redo their bad works[1]. But the best thing to do is learn and move on to create better art.
1: https://www.yahoo.com/movies/bp/steven-spielberg-finally-adm...
A Million Lines of Bad Code
11–20 of 123 posts
Re: A Million Lines of Bad Code
#12I kept some of my original bad C, asm, and REXX code back from my high school days after I finally moved on from BASIC in 1991. I pull it out from time to time for a quick chuckle.
Re: A Million Lines of Bad Code
#13Not quite right. All the code I wrote last year looks bad to me; naieve, clumsy, artless. Because I have learned so much since then. It never gets any better. Not because I don't get better; because I DO get better.
I've been writing code since 1976.
Re: A Million Lines of Bad Code
#14I recently read the book "How to Win Friends & Influence People", bad title great book. My main take away from this is I've been talking to people really badly for the last 27 years. I wish I had read this book in middle school. But this blog reminded me of some of the concepts from the book, its far more productive to give positive encouragement than to give negative feedback, and just adding a complement isn't enou…
"Hey pretty cool program! Its a great start. I bet we can make it run faster if we changed the way files are imported to something like this... nice work" I usually hear this referred to as a "criticism sandwich": Criticism surrounded on either side with compliments.
In the martial arts community we call this "praise, correct, praise."
Re: A Million Lines of Bad Code
#15I think this is reasonable, but at the same time, please get those million lines out of your system on somebody else's project.
If that can't be done, if you can't spend your free time honing your abilities, then accept helpful feedback from other more experienced developers. Don't just accept feedback--assume your code is garbage, and ask how you can make it better. If the answer eventually becomes "it's good enough for business purposes", then find out why that is, and learn from that.
Communication is hard, and explaining why a codebase is just wrong can be as difficult as explaining to somebody why you find them abrasive.
At the same time, it's the job of senior engineers to make the effort and try.
Sadly, in a startup environment, it's usually smarter business-wise in the short-term just to sack the inexperienced developers or railroad them into simpler work that they can't screw up, and kick the can down the line.
Re: A Million Lines of Bad Code
#16I recently read the book "How to Win Friends & Influence People", bad title great book. My main take away from this is I've been talking to people really badly for the last 27 years. I wish I had read this book in middle school. But this blog reminded me of some of the concepts from the book, its far more productive to give positive encouragement than to give negative feedback, and just adding a complement isn't enou…
I like teaching. I don't think I'm amazing at it, but I like sharing knowledge and experience with my friends and co-workers and see them improve, or just sometimes for the abstract sense of helping. Of course, sometimes I fall flat and come across as arrogant or condescending, but I hope that's rare. I read "How to make friends" a long time ago, and I apply those rules diligently to my interactions with people.
Recently though, I've been assigned a guy to help me with one of my tasks, managing the build pipeline. This requires a wide range of knowledge about unix and scripting (Bash, Perl AND Python. Yup. On top of Makefiles, of course).
The guy doesn't know how to use a command-line.
I'm surprised to find myself to be very unhelpful and curt with this guy. He's the unlucky recipient of my resentment at the amount of effort I will have to put in before he can actually become remotely helpful. Of course, it doesn't help that he's in far off timezone where I'd have to stay up late to help him, and that I have trouble getting direct answers from him about his knowledge level. The communication and experience gap is too large.
Anyhow, this is just my two cents relating an experience to show how a seemingly normal and friendly human being can revert to angry "RTFM"s.
Re: A Million Lines of Bad Code
#17> Building a string with a series of concatenations like this is extremely inefficient No. Not in Java since 1999 or so.
I built a string this way in java just 5 years ago. Still made it 100x times faster by using a StringBuilder.
Re: A Million Lines of Bad Code
#18I recently read the book "How to Win Friends & Influence People", bad title great book. My main take away from this is I've been talking to people really badly for the last 27 years. I wish I had read this book in middle school. But this blog reminded me of some of the concepts from the book, its far more productive to give positive encouragement than to give negative feedback, and just adding a complement isn't enou…
What's interesting is that XKCD shows replies that are even worse than your last reply- even suggesting Googling provides a course of action. XKCD's more like "My grandmother could read files faster than that."
Re: A Million Lines of Bad Code
#19I remember reading some advice like this around the time I started programming. It was something along the lines of "every dev has XXXXX lines of bad code in them, so write a lot of code to get them done with!". (I think it was from Joel Spolsky, IIRC.) It helped motivate me to just write a ton of code, even early on when I didn't really know what I was doing. Just writing a bunch of code without worrying too much about if it's "right" or not is really important, at least early on.
I think I write better code now because I spent so much time just writing stuff early on, and learning from my mistakes. That, along with some good mentors helped me so much more than the people that merely criticize you because of your code. I definitely agree with this article.
Re: A Million Lines of Bad Code
#201000000 lines of bad code is a bit of an exaggeration. Many (most?) programmers never write that much code in their entire careers. I've heard 10000 LOC as a milestone for REALLY learning a language (once you're familiar with programming in general), I'd say it's on that order of magnitude for writing non-terrible code in general.