Live data from Hacker News

What most young programmers need to learn

joostdevblog.blogspot.com

11–20 of 108 posts

Re: What most young programmers need to learn

#11
I'll add to the list:

- The inability of younger pears to ask for help or otherwise design reviews before they write the code.

- Super hero programming which most of the time boils down to the above and various forms of pseudo-optimisation that are difficult to read. E.g. messing with inheritance and directions: UpwardEngine --- inherits ---> DownwardEngine, instead of using a BaseEngine, because it's saves one class definition (and improve dispatch performance...)

Another advice I would give to young developpers, is that getting as much as possible bits written helps getting better. The thing is that reading code to refactor and debug given the chance to do it right is more difficult and more rewarding in terms of skills.

Re: What most young programmers need to learn

#12
One thing that should be mentioned here is that the amount of time that one has to learn to write code really depends on the company one works at. If you work at smaller firms, its much harder to justify putting in extra time beyond just making it work (although this bites you in the long term by making the codebase uglier). In the larger firms, you have much more time to do code reviews and refactoring.

Re: What most young programmers need to learn

#13

I'll add to the list: - The inability of younger pears to ask for help or otherwise design reviews before they write the code. - Super hero programming which most of the time boils down to the above and various forms of pseudo-optimisation that are difficult to read. E.g. messing with inheritance and directions: UpwardEngine --- inherits ---> DownwardEngine, instead of using a BaseEngine, because it's saves one class…

My opinion is that most of the bad habits of inexperienced programmers are just manifestations of more general youthful hubris and inexperience in the nuances and complexities of life.

I'll add to the list the most extreme form of 'not written here syndrome': 'I didn't write it syndrome'. The programmer sees themselves on missing out on the fun of solving a task by using a library (or reading the relevant framework docs). When experience teaches you that the real misery comes down the line when you need to support your hand-rolled physics engine lacking in tests...

Re: What most young programmers need to learn

#14
What I've been surprised to learn after leaving school is how important it is for code to be stylistically sound: programmers should be as thoughtful about the structure, readability, and conventions of their code as professional writers are of their prose.

This was something that didn't dawn on me until reading Matz's philosophy of "programmer happiness" when designing Ruby. Code seems sterile, something that you just put into place in a logical manner until it works...in small class projects, you don't realize the mental toll it can be to read through a messy code base...But being unhappy about a monolithic, massive codeebase is easy...the problem is tha when working on small projects, you don't notice the mental tax of unclear code that can drain your happiness and productivity.

It took a long time of professional coding for me to realize how much thoughtful design of code could make me a happier coder, just like the adept use of language contributes to happier communication in all other areas of life

Re: What most young programmers need to learn

#16
post #3

> Code in comments [...] When asked applicants are usually well aware that commented-out-code is confusing, but somehow they almost always have it in their code. To my experience this is a common symptom of not using a version control system. You change a line of code, but you want to be able to undo if it doesn't work, possiblay half an hour later when you changed other places of your code (so your editor's undo is…

I am guilty of commenting out code when I am working on a problem, but before committing I remove it unless it is the simple version of some function that I made way too complex in order to improve performance. I find it easier to understand later what the complex code is supposed to be doing if I have the simple implementation in the comments.

I wouldn't call the simpler implementation "commented out code", as it's doing what the best comments are doing, making complex code more readable.

Having random scribbles, alt solutions and other "shitty" comments while working on a problem is definitely not a sin if you clean them up before pushing them forward.

Re: What most young programmers need to learn

#17
post #15

I keep hunting for such a post specifically for an iOS Developer.. to get beyond the initial frameworks and learn processes and flows

Everyone hates to do it, but a lot of this comes from reading code. The more code you read, the more you'll learn to understand idioms, styles, what makes things good and bad for understandability. Then you'll be able to do it yourself.

Another point to make: while every language has it's own idiom and style, there are also lots of "clean code" lessons that apply across languages, so guides about, e.g. python, translate somewhat into objective c.

Re: What most young programmers need to learn

#18
I'm just not sure you can teach these things to a junior programmer, and actually expect to see results. A baby takes 9 months to develop, you can't expect to see finger nails develop until they've developed fingers.

As a junior, you're probably spending most of your time (and a lot of it at that) just trying to make the dang code work. Making sure it's written in a way that other people can maintain it etc is secondary, because who cares if you can maintain it if it never even worked in the first place!

When working with a new junior, It's important to expose them to existing (good!) as well as bad code bases. At the same time, let them write new code on things that aren't super business critical. You have to accept that it's going to take them some time to learn, and you should just work with them until they don't have to think about breathing any more.

Re: What most young programmers need to learn

#19
post #15

I keep hunting for such a post specifically for an iOS Developer.. to get beyond the initial frameworks and learn processes and flows

Everyone hates to do it, but a lot of this comes from reading code. The more code you read, the more you'll learn to understand idioms, styles, what makes things good and bad for understandability. Then you'll be able to do it yourself. Another point to make: while every language has it's own idiom and style, there are also lots of "clean code" lessons that apply across languages, so guides about, e.g. python, transl…

It depends on what code you read, though. Think of PHP devs that learn from WordPress, for instance. It's not exactly setting a great example... (Though to their credit, WordPress improved somewhat in recent years.)

Re: What most young programmers need to learn

#20
post #15

I keep hunting for such a post specifically for an iOS Developer.. to get beyond the initial frameworks and learn processes and flows

Everyone hates to do it, but a lot of this comes from reading code. The more code you read, the more you'll learn to understand idioms, styles, what makes things good and bad for understandability. Then you'll be able to do it yourself. Another point to make: while every language has it's own idiom and style, there are also lots of "clean code" lessons that apply across languages, so guides about, e.g. python, transl…

Reading code is a good start, but I've found that it's not enough. When faced with an unfamiliar concept, I'm not sure whether it's an unfamiliar design pattern, a hacky kludge, or a special case to get around some quirk for a particular use-case.

I've found that reading books—such as the Pragmatic Programmer series, Effective Java, and others—helps me to understand the rationale behind what otherwise seem like strange (sometimes even boneheaded) design decisions. Even oft-derided patterns (such as the "FooBuilderFactoryBuilder" so often seen in the Java world) make sense when understood in the context of the problems they're trying to address.

Post reply on HN