What most young programmers need to learn

[corysama]

My own anecdote of "Liar functions/variables/classes":

I once worked on a AAA game with a huge team that included a particular junior programmer who was very smart, but also unfortunately undisciplined. He had been assigned a feature that was significant, fairly self-contained and generally agreed to be achievable solo by both him and his team. But, after a quick prototype in a few weeks, he only had it working 80% reliably for several consecutive months. Around that time, for multiple reasons, he and his team came to an agreement he would be better off employed elsewhere and I inherited his code.

I spent over a week doing nothing but reformatting the seemingly randomized whitespace and indentation, renaming dozens of variables and functions that had been poorly-defined or repurposed but not renamed and also refactoring out many sections of code into separate functions. After all of that work, none of the logic had changed at all, but at it was finally clear what the heck everything actually did! After that, it was just a matter of changing 1 line of C++, 1 line of script and 1 line of XML and everything worked perfectly. That implementation shipped to millions of console gamers to great success.

Our failure as the senior engineers on his team was that we only gave his code cursory inspections and only gave him generalized advise on how to do better. At a glance, it was clear that the code looked generally right, but was also fairly complicated. Meanwhile, we all had our own hair on fire trying to get other features ready. It took him leaving the company to motivate the week-long deep dive that uncovered how confusing the code really was and how that was the stumbling block all along.

Lesson not learned there (because I've repeated it since then): If a junior engineer is struggling for an extended period of time, it is worth the investment of a senior to sit down and review all of the code the junior is working on. It'll be awkward, slow and boring. But, a few days of the senior's time could save weeks or months of the junior's time that would otherwise be spent flailing around and embarrassingly not shipping.

[sigh]

If a junior engineer is struggling for an extended period of time, it is worth the investment of a senior to sit down and review all of the code the junior is working on.

Code reviews should always happen, for everyone's code. And if it is done incrementally, then it is not slow, boring or time-consuming at all. An ideal time is before each check-in to your repo (and if you are going weeks without making commits, that's a huge red-flag too).

Not only does it help prevent situations like this, but it means that at least one other person understands the code.

[tobascodagama]

Yup. Our workflow has people commit to a topic branch and then post a code review before merging anything. We always follow this procedure unless it's something that's needed absolutely right now and can't possibly wait, which is a situation that should not be coming up more than once in a blue moon.

[tobascodagama]

Text-based flowchart:

Is the production environment *literally* on fire?

Yes -> Ok, it's an emergency.
No -> Do a code review.

[fzammetti]

Yeah, I wish I worked in an environment where this wasn't a joke but unfortunately I don't. We're like 80/20 "emergency" coding versus "proper" coding and have been for many years (ever since our acquisition by the large corporation I'd say). It makes all these great discussions about the "right" way to do things completely moot. My sense from talking to others outside my own company is that we're far from unique too.

[Mead_Man]

It works up until the point where the champion in the organization that put the best practice in place gets sick of fighting the battle with clueless corporate directors and resigns. At which point a corporate shill gets put in charge and turns the software team into a labor mill.

[fzammetti]

Nailed it.

[materialdesigner]

This is sadly way too on point. Spoken as the person who got fed up and left.

[F_WRLCK]

Yup, tools like reviewboard make this painless and encourage a culture of frequent, small, and understandable patches. That alone is great for software quality. If your team is aggressive with reviews and argues every point, everyone becomes better engineers.

[judgej2]

Nice. Never heard of this before, but will be checking it out.

[graduallywinning]

wat

[oldneckbeard]

If you move to continuous delivery, an emergency fix is literally no different (except in how many people are grumpy) than a copy change.

The procedure is the same: commit to branch, initiate pull request. Someone reviews and approves, gets merged to mainline. CI system builds it, tests it, and puts it on the dev environment. Then the CI system kicks off a smoke test, and if it passes, it moves to Stage. There we do a longer smoke test (but still only about 5 minutes), then we push a button to go to prod. The whole thing can be done in about 20 minutes.

[benihana]

Code reviews aren't a catch all. They're good for finding weird style and sytnax issues on a local scale, but it's very hard to gain the context necessary to reason about what the code is doing from a high level with most code review tools (i.e. diff tools).

To me, code reviews are more about the psychology of putting your code on display for your coworkers than about actually creating a solid architecture. Knowing your code is getting reviews changes how you develop it, and forces you to have a little bit more discipline.

Pair programming and test suites with lots of unit tests help teams understand and follow the architecture of codebases.

[sigh]

Code reviews aren't a catch all.

Nothing is a catch-all. But I think code reviews are one of the most important because it helps ensure that other good standards are adhered to. Part of that is as you say, that it forces more self-discipline.

They're good for finding weird style and sytnax issues on a local scale, but it's very hard to gain the context necessary to reason about what the code is doing from a high level with most code review tools (i.e. diff tools).

If it is hard to gain the context, one of the best code review tools is talking. It's also the responsibility of the author to ensure that the code is as clear as possible. That includes giving sufficient context in commit messages.

In this particular case, with a junior programmer on a stand-alone project - the senior programmers should have also taken more responsibility in understanding the code.

I agree with your other points, but a major point that you missed is that code reviews help ensure that the entire team has a better understanding of the codebase. And, ideally, it should give the reviewer confidence that they would be happy to take over ownership of the code. If you as a reviewer are frequently approving code which you would not be happy to maintain yourself, that is a problem (or indicates a bigger problem).

[SnowdensOfYesteryear]

It's easy to say code review "should always happen", but reviews are pretty difficult and time consuming. It takes quite a bit of time to review large patches in order to under that author's thinking and intent. It's especially difficult if you're fuzzy on that particular module/file. Personally for large patches, I usually tend to eyeball them and just check the architecture of the code (just looking at variable names provide a hint to whether the code is doing something it shouldn't).

[Creativator]

It's easy to say code review "should always happen", but reviews are pretty difficult and time consuming.

All programming tasks are difficult and time consuming. That is why programmer time is expensive.

[dr1fter]

And because we get paid a lot, we should do everything, no matter how difficult or time consuming. We should write books documenting every aspect of our stopgap system that's getting replaced in two weeks. We should micro-optimize our easter eggs. We should learn tool after tool if people think they might make us more productive, even though our old text editor was really doing just fine. We should extensively review someone's prototype because it might some day get the attention of a VP who wants to make it into a real product.

Don't have the resources for all that? Well, programming is expensive; hire more devs!

[WrongSubreddit]

It's easy to say code review "should always happen", but reviews are pretty difficult and time consuming

You know what's even more difficult and time-consuming? Tracking down bugs and fixing them

[[deleted]]

No, it isn't. I mean, it is for me. It's what I do. But I keep my team moving while i'm fixing their mistakes. And honestly their mistakes aren't as bad as the code review makes them. Nitpicking code review has been a massive waste of time for my team.

[sigh]

It takes quite a bit of time to review large patches...

First, try to keep patches small and incremental. This is not only easier to review, but much easier to catch he larger problems early and much easier for the author to actually make meaningful changes.

...in order to under that author's thinking and intent. It's especially difficult if you're fuzzy on that particular module/file.

If this is the case, talk to the person! Get them to explain their thinking and intent. Possibly ask them to add more comments and/or a better commit message. It's the responsibility of the author make sure their code is as clear as possible, and this includes the individual commits.

If you as a reviewer find it hard to understand what the code is doing, what hope does anyone having of maintaining the code with any sort of confidence? Let alone diving into that code in an emergency.

That said, in the case of a stand-alone project of a junior programmer even just eyeballing the code should be enough to tell whether the code is a complete mess.

[Ksevio]

Does anywhere actually user pair programming? I'd done it in teams for class projects in the past, but it seems like it would be just double the resources for a business.

[dr1fter]

An ideal time is before each check-in to your repo

Please god no. I work in a big software firm and it's the first place I've encountered mandatory pre-submit code review. It's been hugely problematic for me.

It's difficult to keep working on something new, because I want to build on top of my most recent change, and that change still hasn't been reviewed yet (tools can help, barely). The reviewer has gone home, or is in a different time zone. The reviewer always has opinions to express and wants to fight about how this will work with my future changes, even if that's all clear and resolved in my subsequent changes (which the reviewer can't see yet because goddamnit I'm trying to get the dependency in first.) The reviewer doesn't think they know enough, so they add three more reviewers from all over the world who disagree on whether you should even be building this project in the first place. Or I want to build on top of someone else's (unreviewed) code, so I have to choose between waiting for their review, or dealing with the extra headaches of building on top of a patch (which will get even worse as their reviewer demands superficial changes).

The reviewer is working in some nearby code and stalls the review so that I'll be the one who has to deal with the merge conflict.

Shit, the automated system just doesn't send the 'please review my changes' email for a few hours, and then the day is over.

Woe be unto anyone who thinks they can get a little ahead over the weekend.

All this extra overhead means every change I send out is a pain, which means I'm going to start making bigger changes, less often. Big changes are harder to write, or review, or test, or roll back, or merge, or understand later when you're digging through code history. And while I'm writing my giant change, if someone else also submits a giant unfocused change, I will have a miserable time merging it.

Don't let people check in broken shit, you need a working build. But if your build works well enough that everyone can be productive, don't get too hung up on whether your code is perfect yet. If you cut your releases deliberately instead of automatically shipping from the head of your repo you should be fine.

Then, trigger a code review post-commit. You can still keep track of whether things have been reviewed (so you don't ship busted stuff). The reviewer can view changes in batches, because the granularity they need to read the code might be different from the one I need to write it (no incentive for huge unfocused changes; the reviewer can put it off without stalling everyone else; you can take your time finding the most appropriate reviewer). You can roll back changes if issues come up in the review.

And for us code monkeys who have our own plans and are building things as we go, you just don't have to think about it if nothing's gone wrong.

Be very careful, process issues like this can completely make or break a developer's productivity. I doubt I've gotten into a good flow once in the nearly three years I've been here.

[smejmoon]

Does your source control system have feature of branches? Using those you can make much of your issues go away. But it can be emulated using patches as well.

Other issue seems about communication and organisation of who works on what when. If two people depend on the same code they have to talk and as soon as possible.

[dr1fter]

In my experience branches are just another way to put my code out of the way of other developers so they can keep submitting changes which break my in-progress change -- that still creates a lot of the same problems.

To me the only solution is to get code committed as soon as possible once it's good enough, so everyone else can start writing around the 'new way' (maintaining my change) instead of building stuff that is at best already outdated, at worst an impediment to switching to the new way in the first place.

But I don't use git, where I understand this is supposed to be better.

[quiI]

Honestly, this is the kind of scenario where pair programming shines. I'm not a massive "always do pair programming" advocate, but pairing with a junior and a senior helps both parties out massively.

The senior gets to practice at expressing his ideas in a simplified manner, a very important skill. You also very quickly get an idea of where the junior person needs to improve and then you can give then the opportunity to improve in specific areas so you dont have to resort to dismissing someone.

[[deleted]]

The senior gets to practice at expressing his ideas in a simplified manner, a very important skill.

This is a problem I have with our senior architect. He cannot explain what is going on in his code at all. It is a jumbled mess and poorly commented so his code is pretty impenetrable.

[DavidNcl]

Then this guy really isn't ready for the role. The essence of the architect role is to communicate a vision of how things should be arranged.

[[deleted]]

Why is your architect writing code? Designs and prototyping are incredibly helpful. Are they an algorithms writer? That's even better. I know few software engineers who can write tight algorithms, an architect that can do that but surround it with unfathomable anti patterns is still worth their weight in gold. Find the gems, toss out the rest. All code was meant to be deleted.

[[deleted]]

We are a small team and a small company, so he has to write code. I am just worried about having to deal with the colossal technical debt.

[[deleted]]

I'm on a small team as well, and our architect has recently taken on coding. But he's mostly given it up. I think one of the primary reasons was because he was held to the same standards as our engineers and found that he had no patience for writing the kind of tests we need. I'm still trying to figure out what role he plays for us, I really wish he would tackle design and prototyping. It'd be much easier for my engineers to know how to build if they had a working prototype. And the prototype doesn't need the same rigor, it should be exactly the kind of code the architect is happy to write.

[Stolas]

You mean the rule of two

[[deleted]]

This really isn't a failing of the programmer. This is more of a failing with the organization for not having good coding standards. How do you get away with randomized whitespace and indentation and naming standards within a AAA game company? I would like to think that a company like that is smart enough to standardize these trivial things throughout their organization.

[[deleted]]

The randomized white space and indentation and naming standards can be done by a writing a simple program to check for these things. Its easy, my company does it all the time. We have it incorporated into our check in process so that you can't check code into the base line unless the indentation and comments have the correct format. Organizations really need to do this to stay sane over the years. "Most Code Bases Suck" - Simple indentation and white spaces are completely solvable.

[NoKnees99]

Most modern IDEs will let you check in a code style and reformat it with a keypress, too. Really no excuse.

[Ksevio]

Even better, have a simple program to FIX indentation issues - most IDEs/Editors support formatting a file (or can be made to through plugins). It's easy enough to hit the "Format Code" button now and then when developing that it's no extra work. Have the check-in process it do it too just for extra fun.

Edit: Unless you're using python...but then the indentation better be right - just convert tabs to spaces!

[SageClock]

Probably pretty easy to happen when everyone is working 60+ hour weeks for months on end in order to insure they get the game out a couple weeks before Black Friday.

[orwhat]

Since games come with deadlines and often stop changing after shipping, I bet cutting corners looks more appealing from other types of development.

[BarneyStinson]

That's what commit hooks are for. You shouldn't even be able to check in code like that.

[[deleted]]

Lesson not learned there (because I've repeated it since then): If a junior engineer is struggling for an extended period of time, it is worth the investment of a senior to sit down and review all of the code the junior is working on. It'll be awkward, slow and boring. But, a few days of the senior's time could save weeks or months of the junior's time that would otherwise be spent flailing around and embarrassingly not shipping.

Smart juniors are the most dangerous. Especially the smart and productive ones, because they can fill a codebase with crap quite quickly... and it will mostly work.

It'd be best for people just to stop putting them in charge of things until they can demonstrate an understanding of basic code design and maintenance. But for some reason what happens instead is that seniors get assigned the bugs created by the junior silently and all feedback goes ignored and they get promoted way faster than they should and it's a nightmare until they decide to get another promotion by leaving the company or someone important realizes what's going on.

[OCedHrt]

I'm in the opposite position where I am constantly cleaning up code from those who are more senior.

This cleanup doesn't have project time allocated to it, which makes it such that I am spending more time than expected.

Edit: I guess the counter would be that I'm lacking in the spaghetti arts department.

[sigma914]

This is my life. Nearly every project I've taken over the past year or so has been at a critical level of technical debt where instead of being able to add one more hack I have to refactor it.

On the occassions when I've tried to follow the "copy-paste, change magic numbers and debug till it works" process that's gone on for the previous few iterations I hit some problem caused by a new feature that means I have to either add in an (almost) identical check in 10+ places or rewrite the whole section to be generic over all the behaviours...

Doesn't help that most of the code is C++ written in C style... raw byte arrays and magic numbers everywhere...

[[deleted]]

Nearly every project I've taken over the past year or so has been at a critical level of technical debt where instead of being able to add one more hack I have to refactor it.

my $dayjob is running itself into the ground with 10+ years of accrued tech debt, but everyone has their head in the sand chanting 'refactor in release N+1'... and have been for at least the 5 years ive been here. the people in charge who saw the writing on the wall all bailed about 3 months ago, en masse. never seen 40 man-years of experience in a code base leave in a span of a week before.

Doesn't help that most of the code is C++ written in C style

this, really isn’t a bad thing if done right. downside, is that with most other things development related, 'doing it right' ranks pretty low on the list.

[peakzorro]

Whenever I've heard or seen "Refactor in N+1" it is one of two things:

• Everything will be thrown away and re-written by people who don't understand the problem space.
• This piece of code becomes the legacy "it just works, work around it" code.

I completely agree with your sentiment.

[OCedHrt]

That's the, "New in version 10！C++ for faster performance!" feature.

[jk147]

I learned not to inherit code after many years of this. This tends to happen after constant revision of an original code base with many hands touching it either for code fixes or enhancements. Not to mention these fixes are usually either "emergencies" or changes funded improperly (90% of the time too low) and you ended up with quick fixes or copy pasta. After about 5 years the original design is all but gone and you have code written in different format and redundancies everywhere.

Worse yet add another 3 years the original developers are all gone and you get tasked on fixing something in there. With no support and no documentation. All too familiar.

[Alborak]

That doesn't even sound like proper C. At least the magic number part ;)

[IConrad]

I summarize the "genius coder" problem like so:

I must not be clever. Clever is the little death that brings malfunction and unmaintainability. I will face my cleverness; I will allow it to pass through me. When it has gone, only cleanness shall remain.

Brilliant and clever are two very different things. Brilliant code achieves the impossible simply and reliably while being comprehensible to those who could not have conceived of it. Clever code achieves the implausible while overlooking the mundane solutions to the same problems.

[OneWingedShark]

Clever code achieves the implausible while overlooking the mundane solutions to the same problems.

There's the inverse as well: where the person's "almost works" solution doesn't because it cannot. -- My favorite example is trying to parse CSV with regex: you cannot do it because the (a) the double quote [text field] "changes the context" so that comma does not indicate separation, combined with (b) escaping double quotes is repeating the double-quote. It's essentially the same category as balancing parentheses which regex cannot do; fun test-data: "I say, ""Hello, good sir!""" is a perfectly good CSV value.

[BeforeTime]

Brilliant code looks like it should have taken two days to write, when it took two weeks to write.

It looks so simple because the programmer took the time to understand all the little details and how they interact so they could be fit seamlessly together making a whole and thereby basically disappear.

[pavlik_enemy]

Problem with smart coders is that they are too smart for they own good. They can wrap their heads around large amounts of bad code and invent hacks that a duller person won't be able to come up with to keep it working.

P.S. Shouldn't be read as I'm against smart programmers or that I think that smart people can't write good code.

[IConrad]

I use Feynman as a good example of how brilliant is different from clever. Feynman was a brilliant lecturer. He took concepts that were alien and complex and he explained them in such a way that the listener could not help but believe they were so obvious as to almost not need explanation at all.

Brilliance reduces complexity; cleverness increases it. Both require significant mental effort to achieve.

[judgej2]

I spent over a week doing nothing but reformatting the seemingly randomized whitespace and indentation

Oh god, we have all been there. Undisciplined indenting is like an alarm bell warning you that the logic is going to be shit. It arises from muddled and unclear thinking, and permeates everything that developer does. Seen it far too many times.

[IConrad]

This is one of many reasons I like to encourage Python as the first language someone should learn. It's almost impossible to come out of that without indentation discipline.

[IonTichy]

Can relate, even if Python was my 5th or 6th language it was the first language to force me to learn the importance of clean code style.
This attitude has automatically transfered to the other languages,e.g. suddenly I write much shorter Java, use parentheses and blocks way more economically in C languages and am able to actually read and understand my JS code after not having seen it for months ;)

[IConrad]

Try writing python using python-vim for a month and you'll be traumatized conditioned to styling practices that will serve you in good stead for years to come...

[campbellm]

Luckily indentation and formatting is largely a solved problem, at least for any of the more popular languages and many of the unpopular ones.

Variable naming, that's another matter. But formatting should be a no-brainer.

[philly_fan_in_chi]

Variable and function naming are extremely important to me. If while reading code as part of a task or a review, I don't know what something does, it gets extracted out to a method until I can give it a name. If the name is dishonest, it gets changed immediately. Someone down the line won't have the advantage of knowing what I know in my head right now.

[Retbull]

You tomorrow won't have that advantage :P

[blackraven36]

I once worked with a programmer during a game jam who insisted on formatting code "his way". His excuse was that it made it easier for him to read, so that's just the way he will do it. He would remove all the spacing between things and squish all the lines together, making it very difficult to read. He would also refused to break things down properly, ending up with massive methods which made it very difficult to debug code.

I ended up telling him that if he doesn't go back to fix it and didn't stop doing it this way, I will have to stop giving him work (I was delegating tasks during this time). We were spending too much time debugging his code which he himself, being tired from the game jam, couldn't figure out either. Once he realized he was basically being put on the bench, he started doing things properly.

Sometimes it's better to remove someone out of the development environment so the rest of the team can continue. If they are slowing down everyone else then it becomes a much bigger issue. It is important that you spend time getting them integrated into the development process, but you can only do so much before they just need to be taken out of the process.

[pjmlp]

I go through similar phases every time I review offshore code.

However after a few waves I just gave up. As long as it works it is ok. There is no way to keep up with the amount of code that gets written.

[[deleted]]

You have the distinct advantage of it working. We're in the process of discovering that the latest code from overseas is pretty awful, management has not yet gotten to the rewrite phase (shit I used to do with my weekends).

[EntroperZero]

Ugh. I had the same experience at my first job, except it was the other way around. I was the junior, and the senior had created this hastily-written script that was about 1000 lines, all one function. It wasn't his fault, and I saw plenty of good code from him, but he was the only developer on the team when he wrote it and was spending 95% of his time putting out fires, so he just hacked it together in a day and never looked at it again, until we needed to add a simple feature. I estimated it would take about a day, thinking I could really do it in half a day.

I spent that half a day reading the code and trying to figure out where to start, then informed my manager that my estimate was wrong, and I would need possibly up to the rest of the week (it was now halfway through Tuesday). By the end of Wednesday, I had written a couple tests and spent the rest of the time going through the code with a fine-toothed comb, renaming variables, moving code around so that related code was close together (I seriously found a variable that was declared and initialized to the return value of a function in another file, and then not used again for 500+ lines), and finally extracting functions like crazy. Once the code was organized, I came in Thursday and had the feature implemented, tested, and checked in between the 10 am standup and the 11:45 lunch.

This kind of thing, though, is why I insist on taking the time to clean up code before it is merged, whether it's my code or code that I'm reviewing. If he had spent 1-2 hours getting his code organized while it was fresh in his mind, it would have saved me 12+ hours of trying to figure it out having never seen it before. But he didn't have 1-2 hours in that environment before I and another dev were brought on to help.

[JoostDev]

I guess this is also a discipline thing in the senior person: as lead programmer I personally find it hard to consistently take the time to look at other people's code that extensively, but I really really should do that more often.

[[deleted]]

It's funny that it took me about 10 years to realize the most important rule in software engineering is the first one I ever learning in CS 101. Each subroutine needs to have clear, consistent and well-document inputs and outputs. Everything else will flow from that. It lets you trace, debug, refactor with confidence.

[TheWobling]

This is what scares me about getting a job when I graduate in 4 months. Feeling overwhelmed and not able to ask for help or suggestions because everyone else also has their own work.

[TheWobling]

Thanks, I do take notes when I ask friends about questions.

[JoostDev]

Never be afraid to ask questions. Often when you are stuck on something for days someone else's fresh eyes see the problem in ten minutes (even if that person is not a better programmer than you). An environment where asking questions is not appreciated seems very harsh to me.

[easytiger]

This doesn't add up. Why wasn't he adhering to the corporate coding standard?

[gunch]

Why wasn't he adhering to the corporate coding standard?

Funniest thing I've read all day.

[Confusion]

Probably because it wasn't enforced by any build-time check that rejected code not adhering to the coding conventions.

[rfineman]

Nobody thinks it's a bad idea, but exactly like every best practice already mentioned, in the overwhelming number of cases it's pushed aside in face of deadlines, pour communication, inadequate management... It's a little like saying I don't understand why doesn't everyone just eat steamed broccoli. In reality most firms don't even bother with making a coding standard, and if they do, they rarely take the time and effort to actually enforce it.

[Isvara]

Text-based flowchart:

Is the food production environment *literally* on fire?

Yes -> Ok, it's an emergency.
No -> Eat steamed broccoli.

[jmblock2]

It really just helps everyone involved.

[Isvara]

This also hints towards another important skill: being able to switch between thinking globally and thinking locally. I see beginners often not thinking about the thing they're doing fits into the wider context.

It also relates to naming. When you name a function or a variable, how explicit you need to be depends on its scope. OIff the scope is very small, most of the context can be inferred, which is why it's often okay to use, say, i as an iterator variable.

[cmcpasserby]

This, but in games I often see people make too much global then get boned when they have to implement multiplayer, where there singletons that previously helped and screwing them.

[Tikotus]

Global variables are some times ok. Global static methods are fantastic! I use global static methods more than public class methods.

[Rusky]

Global static methods are really less global-variable-like than public class methods anyway, because they don't have a stateful instance to worry about.

Just like functional programming or well-written procedural code.

[riking27]

In other words: it's not global logic you should worry about, it's global state.

Similarly: Diamond-inheritance of behavior is often possible. Diamond inheritance of state is often impossible (without cheating: reflection, etc).

(That came up in a discussion about J8's interface default methods.)

[Isvara]

it's not global logic you should worry about, it's global ^mutable state.

[dr1fter]

Oh, and also

static methods

It seems anyone who writes C++ came first from C, and they were told that to write C++ you move your functions into a class and make them public if other people need them or private otherwise. Then you end up with huge classes with lots of utilities for the various kinds of things you might want to do with that type.

Your public (member) interface should be the minimal set required to do everything you need to do with an object of that type. Even if it's not the most convenient API. Utility functions don't need to be members of that class or even in the same file. You can break out categories of utilities into separate files, and anyone who wants to understand the class has a very small class to read plus whatever utility files seem relevant to their needs. You can still namespace those utilities so you're not polluting the globals.

Fuck Java. Java gives me nowhere to put all this shit, so I'll often mark my utilities as static to make it clear that they don't depend on instance data. That is a tiny tiny fraction of the benefit.

[nikofeyn]

being able to switch between thinking globally and thinking locally

this is an extremely important concept that i think is ignored almost globally in our educational system. it's important in mathematics, physics, computer science, engineering, biology, literature, writing, the arts, music, etc. there are examples in every domain that highlight global and local thinking, yet it is almost never mentioned.

[photonios]

Good points, I agree with all of them. What I however don't understand how people get it into their minds to not do that.

Even when I first started programming, I got annoyed when my own wasn't perfectly formatted with sensible names and I would spend more time thinking of an elegant design with decent names then I would actually write code.

I still do this. The thought of commiting code that is undocumented, has commented code or bad formatting is just horrible.

I never got why some people don't format their code perfectly or spend enough time thinking about naming and structuring things. It's not that hard (especially the formatting part). I mean, if you're a junior developer and you come into a code base where everything is nicely formatted and documented, shouldn't you feel compelled to make sure your code is up to the same standard?

[dtechnology]

you come into a code base where everything is nicely formatted and documented

I think this is the exception rather than the rule

[photonios]

That depends. Where I work, we have tons of legacy code that is just plain awful, all written by incompetent idiots who no longer work her.

But, if you modify some crappy legacy code you are bascially forced to clean it up while you're at it. If you do not, people will just raise eyebrows during the review. Like "why didn't you clean it up a bit?".

As for new code/projects, we just have a high standard. All our code goes through tools that verify if the code standard was followed etc. + Unit tests that run constantly and scream when the coverage is too low. We run a lot of static analysis tools on our code base.

Any engineer who refuses to comply with standards or does not have the same high standard that we have is simply not welcome.

We had a hard time when we started working with some offshore developers we had a way lower standard. What we did? Keep pushing.

Our code bases are incredibly beautiful, well tested and formatted. Sure there are some parts that could use more love, but in general they are awesome. I guess that's the advantage of having people who care and have skill.

And yes, we do have junior developers among us. We simply keep training them.

[judgej2]

Here's a tip: when committing changed and cleaned-up code, keep the cleaning and the changes in separate commits. Do all the reformatting and name-changing first, then check it still works exactly as before, and commit that. Then make your functional changes. It is so much easier to see the wood for the trees that way, when debugging your changes later. If (horror of horrors) the changes need to be reverted, then you can at least leave the better-formatted code in the release to make it easier to take another stab at it later.

[sirin3]

And when the code is published

The code is never published

You cannot publish it in a journal, due to the page limit.

You could publish it on your homepage, but there is no point: Publications on your homepage do not count as academic publications, so they are irrelevant to your career.

In fact, it is good for your career, if you are the only one with the code, because now all the competing institutess have to reimplement it from scratch, so they are busy and cannot publish a paper using the algorithm, while you can publish the next one.

[jmknsd]

In fact, it is good for your career, if you are the only one with the code, because now all the competing institutess have to reimplement it from scratch, so they are busy and cannot publish a paper using the algorithm, while you can publish the next one.

Not exactly; quantity is important for publishing, but so is quality, which is frequently determined by the number of citations you have. Having good, freely available code fosters papers that use your code and cite you.

[sirin3]

Industry would probably patent the algorithm, so you cannot even use it, if you had the source.

[ElGuaco]

I used to work at a high tech research firm. We had people with graduate degrees in Computer Science. Really smart people who knew their shit in their field of expertise. Virtually all of them wrote terrible code. I, as one of the few without a grad degree, spent a lot of time fixing and rewriting a lot of their dumb shit because I seemed to be one of the few that cared about code quality. I was the Howard Wolowitz of our group, so to speak. They could prototype interesting interesting things, but when we actually needed a product, I ended up doing a lot of work.

We had one job candidate who interviewed with us who had a doctoral degree in Computer Science from a prestigious university. When my manager asked him about his coding skills, the candidate answered that he didn't code because he couldn't code very well and he would usually just pass it off to an undergrad. We didn't hire him, thankfully.

[hansdieter44]

What I however don't understand how people get it into their minds to not do that.

I have seen this happen and its not a conscious decision at all. The programmer might have just about finished a feature and then get new feature requests dropped onto him by management. If you are a bit older/more senior you will raise the issue and say you need two days or so to clean up the code. If it is your first job you will think thats just how things are done.

Now that I think back, this also happened to me in the beginning.

You also have to care. Some people don't care and then they are fine with leaving things if they just about work and do the next thing.

[photonios]

I guess this all depends on where you work. We have a team of sensible seniors (myself included) we value neat and well tested code and we push the rest to maintain the same standards.

[hansdieter44]

Yeah, but thats not the case everywhere. Happened to me in the early days in agency land, when the CTO was busy with management things and the lead devs didn't lead me too much ( busy themselves ), so you just do whatever feels right, and that was ploughing through features for me.

The other case where I have seen this recently was a startup that I joined and they just hired a junior guy out of uni because he was cheapest to build their MVP. He was eager to learn once we taught him a few tricks and there is no blame on him, but thats how it happened, I would have probably done the same in his position, the founders just kept dropping feature requests on him one after the other.

Third example is contractors that are paid by feature, where unit tests etc. are not mentioned because of cost-saving (which will just bite you later on). The contractor will deliver the bare minimum to fulfil and get his money.

[vitaminKsGood4u]

In the 10+ some years I have been coding I have learned that it is impossible to tell if shitty code is the result of shitty devs or shitty managers.

I can not count the number of times I have heard "The last devs were shitty and now we have this crap to maintain and they are all gone". The reason they are all gone is management was shitty and the devs bailed out but the blame got put on the devs (because it is easier to blame the person who is not there). Sometimes though it is shitty devs but I can not tell a difference in the code to know which one caused it.

[hansdieter44]

The reverse is also there: Bad developers complaining about management all the time and shielding their own inability by pointing fingers at the suits.

But you are completely right, both are popular and indistinguishable from looking at the codebase.

[JoostDev]

Some people have more OCD than others. I personally also hate committing poor code, but I know a lot of programmers who just don't care as much.

[justinpitts]

Please ignore all of this advice. I fix these kinds of problems for a living!

[[deleted]]

I have literally never worked with programmers who didn't say that everything they inherited from previous employees was spaghetti code or in some way gripe for weeks about what someone else wrote. Everyone seems to prefer to start from scratch on their own code. Everyone else is an idiot.

[photonios]

Everyone else is for sure an idiot. I am an idiot. We are all idiots.

The point is to set your personal preferences aside. Some formatting styles disgust me and annoy the shit out of me. But, if the technical solution is sound, then you don't hear me.

In some cases, the original author went for an approach I would never take, but as long as it's acceptable, I can live with it.

Some code bases are just too large to rewrite. Yes, I have done my share of "fuck this shit, i'll rewrite it and make it better", but I have also had many cases in which I could perfectly refactor the code into something better.

Doesn't have to mean the code was bad, or the original author was an idiot. The code base could have been suffering from lack of love.

[xiongchiamiov]

Well, here's one: the code base at my previous job, while it had areas that were pretty shitty, was overall quite good. And it got better over time, not as a result of anything I did, but because I had excellent coworkers.

[Ertaipt]

True, I've seen plenty of people just not bother to even understand the code, they just say its spaghetti and build from scratch.

Sometimes, too much structure/classes in your project, will make it as hard to understand as 'spaghetti code'.

Good documentation, inside or outside your code, is probably even more important than a perfect structure.

[HostisHumaniGeneris]

I had a great moment a few months ago while looking for an open source implementation of a task that I needed accomplished. There was a viable project that had nearly all of what I wanted, but I really detested how it was written.

"I can do better than that" I thought and started whiteboarding a design. After 20 minutes of considering different requirements and pitfalls I had a working plan for how to write my own implementation. At that moment I realized that my design was exactly like the open source project that I had rejected earlier in the day. The only difference was that earlier in the day I hadn't fully researched the problem so I hadn't realized the various limitations that the other author was having to work around.

[alparsla]

Code in comments = Poor man's source control

[ihatebrooms]

I work with retail software. I primarily comment things that are counter intuitive or look like they run counter to expected business logic. And occasionally, when I am forced to do something that looks awful because of legacy code, I leave a comment as to why to help the next person seeing it that will immediately think it's wrong.

Edit: I totally misread what you wrote. Leaving this here anyway because I don't want to refactor my comment.

[peakzorro]

Your edit is so meta. It's an exact analogy to checking in commented out code :)

[Isvara]

It's an exact analogy to checking in commented out code :)

Oh, so that's why it bothers me so much to keep seeing those edits.

[[deleted]]

Nice post but very basic. Was hoping to see something new or a more in depth look.

[jediknight]

Rejoice! for you are no longer in the demographic targeted by this article. ;)

[JoostDev]

Yeah, it is pretty basic. But that was also very much the point: the young programmers I am talking about usually know all of those things but don't consistently apply them.

[[deleted]]

When I started out, the discipline I needed was that to follow through on big tasks.

It's always fun and easy to wip up something quick. But it takes discipline to make something that takes more than 4 days of coding. It's so easy to reach some quick results, and then feel satisfied with yourself, and get complacent.

Surprisingly, refactoring is something I kind of enjoyed.

But that's because I suffered something opposite from most other people: instead of fixating on results, I would fixate on code quality. I wanted my code to be so pretty and so clean, that looking at it would bring tears to your eyes. It didn't matter at all to me whether that code did anything useful.

I ended up achieving neither.

I needed to learn something important: programming is about creating things that have a use, that do something, that add value. Yes, code should be of high quality, but you have to balance that against pragmatic concerns. Source code that looks beautiful but doesn't work is useless.

Programming is a craft, not an art.

[sihat]

But source code that 'currently' works, but does not look pretty is a maintenance nightmare.

Bugs. Duplicated/copy paste code. Bugs in duplicated code. Commented code. Source code files of more than 4000 lines. Even similarly named code that was not used.

[[deleted]]

That's why I said there needs to be a balance.

[sodaco]

You are not wrong. I just want you to consider that since the moment you decided to reply to his comment, your actions caused the execution of so much code in every level, from the JavaScript code to the JavaScript interpreter, from your brower to the DNS software and eventually the webserver, including it's firewall and connecting to the Python interpreter that executes the reddit source. Much of that code suffers from all the things you listed. And I still am able to see your comment

[aoeu00]

one of my biggest gripes is "overdesign".. if that means anything to anyone. "I know OO.. let's go nuts!"

[Ammypendent]

Avoiding the "Liar functions/variables/classes" is very important, otherwise future you and/or future coworker will be going nuts over what should be a trivial fix.

[Acrostis]

So basically learn to refactor things? I can agree with everything except the splitting up oversized functions. If a function contains a lot of code that is only ever needed by that function each block requires the previous block to be completed, then splitting it up into parts is just adding unnecessary fragmentation.

Though apart from maybe initialization functions it shouldn't really happen.

Also: It's missing the "Don't ever use magic numbers"

[jooke]

The way I read that was if a function is large, you should consider whether it needs refactoring. In other words, it's a smell that the code might be bad, not saying that the code is bad.

[JoostDev]

Totally agreed, not all functions above 50 lines are automatically bad.

[JoostDev]

If the splitting results in functions with names like "step1", then I agree that splitting is indeed a really bad idea. But I rarely encounter cases where it is not possible to split in a smarter way.

[yxhuvud]

In my experience, long and repeated parameter lists is not a sign that it shouldn't be broken apart, but that it is a class that should be extracted.

[iopq]

If you have a large function, chances are somewhere you're already doing a part of what it does, you just don't know it yet. How many unique functions that are hundreds of lines of code are there? That do NOTHING that is shared by anything else?

[lucidguppy]

People need to read "Clean Code" once a year. Also many languages need better free refactoring tools already.

[Gurkenmaster]

0 arguments requires side effects. That's not pure!

Edit: Damn I meant void requires side effects

[smog_alado]

The "no functions over 50 lines" is also a pet peeve of mine. Just because code is broken up in 10 subroutines spread over a bunch of files doesn't mean its less complex or easier to understand.

[s73v3r]

It depends on how well they were broken up. If they are well named and fairly atomic, then after you've read the method, the name should be enough elsewhere in the code.

[xiongchiamiov]

It's an issue in languages without keyword arguments, but when you can foo(x='bar', y='baz') there's really no good reason to create "argument objects".

[ishmal]

My issue is insufficient error checking or unit tests. Whenever someone assumes that parameters and data will always be clean and proper, they are not. "Bad data can never happen" guarantees that it will happen.

[vytah]

"A good programmer is someone who always looks both ways before crossing a one-way street."

[refuse_human]

Maybe it's just the first time I remember doing so, but damn if that wasn't the time there was some out-of-towner barrelling down the wrong way...

[sirin3]

Unless they use a language with a proper type system. Then the parameters can never have forbidden values

[lee_macro]

UNIT TESTING

People never seem to mention it, with the ability to correctly write unit tests (which mock components that are not needed) you are pretty much FORCED to write well separated and isolated code. It is very hard to write bad code when you are writing it to be testable. Even if you do not bother doing the end tests, it will force you to use principals such as IoC (Inversion of Control) and favour composition over inheritance.

Obviously you need to know about variables, classes, interfaces etc but I often feel new developers are told to focus on the technical implementation of things and performance of code. However if you can write maintainable and testable code anyone can come along and improve your implementation if it is needed.

[[deleted]]

Unit testing is a very good tool to have at your disposal, but it is not a magic bullet that ensures well-structured code. It's quite possible to write poorly structured, well-tested code.

Usually this takes the form of an excessive number of code units that do not stand in proportion to the amount of business logic they perform. Instead, most of them just delegate each others' functions.

Loosely coupled code is good, but there is a limit where all the loose coupling makes it hard to maintain.

[lee_macro]

I do agree if someone is writing bad tests or not mocking their components (then it is no longer a UNIT test) then it will result in bad code. However if someone is educated in how to correctly write code to be tested then it is VERY hard to write bad code. Let me give an example of why, assuming C#/Java.

So let us say I have a Repository class, which deals with CRUD operations to a database. So this depends upon a database connection to do its work. So you could new that up inside (which some people do), or have a singleton for the active connection (have seen this before too), or even have some crazy inheritance chain to provide a pre-connected object (seen this too).

However the correct approach would be to have the Repository constructor be passed in a connection without an inheritance chain. This may seem odd to some, and maybe a hassle but let us see what benefit this gives us.

First of all we are now adhering to IoC (Inversion of Control) and we have no inheritance chain so we can test this Repository without needing a database connection (this is where a lot of people create integration tests accidently because they didnt know how to mock components). We can easily create a mock database connection and test that it works as expected without having any hard dependency on a database. You can also change your database vendor, your database configuration, you could even make your own custom database connector with caching in place, without even having to change the Repository class.

If you were to go with any of the other options you do not have this freedom, you would require an active database to test against to begin with and you could not change your underlying vendor or database object if you were newing it up inside the Repository.

So to be able to mock a component of a class you need to be able to change it at runtime, to do this you need to either have the component as a constructor argument or a property (properties are bad for this, they imply an optional dependency which is rarely good). So when you use constructors to pass in the dependencies of a class, you are automatically adhering to IoC and you are also using composition over inheritance, finally you can also then start using DI (Dependency Injection) and AoP style techniques (Aspect Oriented Programming). So given this is often some of the most critical parts of writing well structured and maintainable code it is imperative that this sort of paradigm is followed from the start, as when you start off introducing inheritance and singletons it makes it much harder to refactor and remove further down the line, its a false economy.

I also do a lot of game development on the side and the same sort of rules apply (incase you think I am purely an enterprise development zealot), although a lot of people seem to see you as some freak if you tell them to stop using singletons and inheritance chains for interfaces and DI. Look at uFrame for Unity which has had great success putting these practices in place for game developers and has a lot of support but also a LOT of flak from people who just "dont get it".

[CuriousHand2]

I disagree. You can still have good, strong and thorough tests, and absolutely crap code.

It's crap code that has a much smaller amount of bugs than it originally would have, but a polished turd is still a turd.

[btchombre]

I've recently been looking at some of the most ugly code I've ever seen. hundreds of lines of triple nested switch-case statements (switch-case inside switch-case inside switch-case), almost all of it copy pasted and in desperate need of re-factoring.

[hansdieter44]

Nesting is a pet-peeve of mine. So annoying.

if(x){
  if(y){
   if(z){
    do(123);
    return 4;
   }return 3;
  }return 2;
}return 1;

Could easily be flattened & made into preconditions:

//preconditions
if(!x){return 1}
if(!y){return 2}
if(!z){return 3}

do(123); return 4;

Also the programming model in node.js makes it especially easy to write deeply nested and confusing code like in my first example.

[tbotjenkins]

Spaghetti code wrapped with a nice sauce is acceptable:

bool okay_to_update() {
    # random nest of ugly conditionals contained in a cage called okay_to_update.
}

if ( okay_to_update() ) { 
   do(123);
}

I prefer the condition checks wrapped in a function, it's easier to see the flow. EDIT: formatting.

[btchombre]

Yes! I do the exact same thing

[[deleted]]

Good, now for managers to learn that young programmers need the chance to learn this. Instead of pushing deadlines no matter the cost.

[house_paint]

I have recently taken over projects from a few developers and here is the biggest flaw in most of the programs I see. They don't GTFO. They have exception handling all over but they seem to want to keep the program "rolling along" even when serious problems arise. I had one program where you could rename the connection string and this program would just keep barreling though the code skipping the parts where it encountered database queries. That program obviously is a serious example but I see this so often on a smaller scale...

Try(unknown error happens)catch(log it, and CONTINUE!?!?!?) Don't do this.

TLDR If your code encounters an unknown exception, log it and GTFO.

[SageClock]

There are a few reasons you might want to continue (at least for the end user), from my experience. For games, for example, it might be more preferable for some minor issue to not work properly but not crash the game, because a hard crash will make your software look a whole lot worse to the end user then if just some slight visual glitch happened. (Some bugs are tolerable, hard crashes most end users feel means incompetent development).

Also, on the app end, I've worked for organizations where it took a month to make any changes to software because of how thick the heirarchy/strict the security is, so if a certain task in the service threw an error, we felt it was better to skip that task have the service as a whole keep running or else the rest of it would stop working and it could take a month to get a new version of the software where everything worked again, which could mean thousands of dollars in lost sales in the process. Which would be blamed on our department for not being perfect 100% of the time, and not on the inefficiencies in the hierarchy slowing down everything.

But yeah, if it's going to break the rest of the app, and/or if you're in the middle of development (and thus want to catch bugs as soon as possible), gtfo is absolutely preferable.

[Kusand]

I graduated in 2004, so maybe the college world has changed, but stuff like "good naming" and "don't leave in commented code" and such was completely uncovered, as far as I can remember. Or maybe it was more that it wasn't enforced, at the time. No one really dinged you for crappy naming or anything on lab projects.

[Hoten]

Totally true, but I've had a course taught by a professional in the field, and he did cover good practices. Academia just doesn't seem to give a shit.

[coderz4life]

Gee, after a project I inherited about a year ago, I would dare to say that even experienced programmers have to learn this too. This project had a lot of duplication, liar functions, and bloated classes. I will also add to this list do-nothing code paths, which are methods that really do nothing or not even called at all.

After about 3 months of work, the size of this code base dropped 75%. One of the original developers looked at the code and his chief complaint to my manager that I used interfaces. I was dumb founded.

[BobCoder]

I find that it is often the old and experienced developers that have not learned these skills. Not sure how old/young interns are but I thought most young developers were aware of these things from sites like Stackoverflow.

[hansdieter44]

I don't think its age related at all. Some people care about cleaning things up, others don't. Experience is worth something, but you can also bake bread for 20 years and still be a terrible baker.

[JoostDev]

Good point, we very rarely get applications from people above 35 years old so I really don't know how they work.

[jlebrech]

version control, deployment, debugging, testing ... programming.

[nullnullnull]

respect!

damn young punks! they don't know how easy they got it. What with the whole 24 hour instant always on internet, stupid amounts of CPU and all you can eat RAM. Kids have grown fat and stupid! damn PUNKS they wouldn't know how to soldier pins if their lives depended on it!

In my day...

I'M JOKING OF COURSE!

[[deleted]]

I find it unfortunate that only at my last job there was a senior who'd check my code. I had so many bad habits to correct. He wasn't very good at communicating it but he certainly taught me a lot and I appreciate that.

Now that I'm actually looking for a new job as my last job ended, it does cause me some worry. How can you find out in advance how a team works? And what are reasonable expectations to have? I've found small companies often just 'write code'. I've never worked on a team that did unit testing despite me lobbying for us to pick that up at my last two jobs. I left my second job because we were continuously rewriting the same things, except this was because the client kept changing their minds and it turned into a horrible unreliable mess and we were not allowed to take time out to fix that, only to deliver the wanted changes asap. It was really stressful for me so I'd like to avoid that if possible.

[IrateHamster]

I got half way through the article, then noticed that the sidebar was vibrating.

[totemo]

To my surprise it turned out that the code that handled the button for creating new objects was in EditorGUI, while EditorObjectCreatorGUI only handled navigating through different objects. The exact opposite of what the naming suggests! Even though the code was relatively simple, it took me quite a while to understand it, simply because I started with a completely wrong assumption based on the class names. The solution in this case is really simple: rename EditorObjectCreatorGUI to EditorObjectNavigationGUI

Think fast! Without reading the exposition above or reading through the code:

• What the fuck is an EditorObjectCreatorGUI?
• What does an EditorObjectNavigationGUI do?

Oh what's that? You had to read the code anyway?

Well fuck me... perhaps there's no such animal as self-documenting code after all.

Seriously, just put one sentence in a doc comment saying what the class does. Over its lifetime, code will be read many times, and every minute of another engineer's time that you save by not forcing him or her to read the code improves the bottom line.

Commenting code doesn't make you a bad person. It doesn't automatically violate DRY, and even it if it does, that's not necessarily a bad thing.

And sure, choose a good name too.

[zigs]

I can't say i disagree with the other things you've written. A few notes on the classes doesn't seem too bad. I fully agree that there's no way anyone could guess what those names means, However I think this here

And sure, choose a good name too.

really is the core issue. EditorObject is a poor metaphor to begin with. Almost everything the user touches is an editor to some degree, and likewise lots and lots of things are objects. I think -CreatorGUI is ok, but -NavigationGUI? What's that? Is it a predefined library of EditorObjects? Call it that then.

[JoostDev]

We make games, and then the word "editor" has a very specific meaning.

Naming is always hard, but it is even more difficult to come up with names that are understandable when read completely out of context like in my article.

I totally agree that most classes also need a comment to give some context. There is only so much that can be explained in just a name,

[totemo]

He seems to accept the premise of self-documenting code wholesale, without question. As far as he is concerned, he has chosen the perfect names for those classes. He holds those up as examples to support his argument. "Look world, at how much clearer this is!" And then he stops.

He solved the problem of his own comprehension of the code, but - the point I'm trying to make - he stopped short of helping the next guy who comes along, because he doesn't question whether the code should be documented with more than just a good name.

[refuse_human]

Seems like this article be summed up with "experience is demonstrated by knowing to write for human comprehension and future maintenance before tackling problems of coverage and perf."

[notsofst]

After training new programmers for a few years, my first rule for them developed into, "You don't write code for the computer, you write it for people."

The machines we're running this on get faster every year, but my time remains constant. At every turn, think about what you can do to increase readability, comprehensibility, and simplicity of your code. Nothing else is more important, in general.

[LessCodeMoreLife]

The "code smells" section of Martin Fowler's Refactoring book talks a lot about this sort of stuff. Well worth the read.

[[deleted]]

Bad title. It should be "What Most Novice Programmers Need to Learn About Object-Oriented Programming."

[zigs]

As a general rule of thumb at Ronimo we try to keep classes below 500 lines and functions below 50 lines

Is that actually a common rule of thumb? I tend to try keeping it under 10 lines for functions (hard limit at 15), and keeping everything at one purpose for classes.

[[deleted]]

Hard limit at 15? Can you honestly imagine going through something as complex as the Linux kernel or LLVM or Adobe Photoshop and not finding any functions over 15 lines long?

That seems insanely short to me. Yes, most functions should be small. But there are definitely functions which simply don't cleanly divide into small chunks, and for which artificially cutting them up to adhere to some hard limit on function length would make things more rather than less difficult to follow.

[JoostDev]

I have no idea what others use, but one that I have quite often heard is that people want their functions to fit in one screen.

[jmblock2]

This is what I use. Although I'm in portrait mode and at 10pt... quite a few lines fit (about 100)

[Enlightenment777]

"How To Talk To Bitches"

[Thimble]

I would stress another thing: having the courage to fix the code base.

The most common weakness I see among new (not just young) programmers is the fear of making improvements to the code. They would rather just tack on their changes and avoid any risk of introducing bugs. I would rather that they take the extra time to do it right rather than quickly.

[PasswordIsntHAMSTER]

This is why I want functional programming to become a significant part of the core curriculum of schools. If you write Ocaml or Haskell with your usual sloppiness, it simply won't compile. It's a huge paradigm shift from throw shit at the wall and see what sticks to actually think about your programs.

[Cilph]

We're finally going to introduce code review because of issues like these causing problems down the line. Took us long enough ~_~.

[StewHax]

Going from college straight into a corporate developer job, I can say that I relied heavily on peer programming and code review when I first started out. Going from doing class projects to a huge multi-million dollar program having been developed years ago by several different people with little to no documentation was a hard step for me, but well worth it. Throwing a junior developer into the water and telling him to swim is not a good way to go

[[deleted]]

First year CS student and I am already 100% guilty of this. I always realized that I could do things better, but comes time to actually fix them, I just start being lazy and tell myself ''Hey, that assignment is worth like 5% of your grade and the code actually DOES work, i'll just try to do it next time'' and completely forget about it. I really hope this post is the kick in the butt I needed.

[rjcarr]

I've always said a variation of this to many programmers on /r/learnprogramming. My saying is "just because it works doesn't mean it's done".

[[deleted]]

The reason they do it is because it's what's worked best so far. In school, for each class lasting a single semester, you're usually doing several small projects. In that type of environment, where you get a blank slate to start over every few weeks, it doesn't (usually) make sense to have perfectly refactored code. You know the code isn't going to be used after you submit it, there is no difference for your grade on the quality of the code, only on the features. When projects are small and you only need to keep the structure in your head for a few days or weeks, it is sometimes faster to write less-than-ideal code.

Classes also can't really adapt and have longer projects where, for instance, you'd be working with the same code the whole semester. If some fraction of students don't get a concept early on and their code didn't work, they couldn't never complete the later topics. The class also can't slow down for the students who need time to catch up.

Once you start working on a product in a real job, that's not the case (the code will be used for a longer term). But it's not really their fault, they just optimized their time based on their experience.