Hacker News Reader

Comment by BigChiefSmokem | Hacker News Reader

Put the newbie gumshoes to work by tracking down simple bugs and designing simple patches to fix them. They need to be able to read other people's code to decipher and debug the coding style they are seeing before they are allowed to build any new module themselves. They need to understand other styles so they can form their own. They should be able to detect any code "smells" and reason with pros/cons why their implementation could work better and provide proof (like execution timing or better readability).

Playing a lot of puzzle games help as well, especially games where the thing to do is very abstract like in a point-n-click adventure game.

View on HN

>> They need to be able to read other people's code to decipher and debug the coding style they are seeing

>> They need to understand other styles so they can form their own

After 15 years of working professionally, I kindly have to disagree to a fair extent. It turns out that most - if not all - developers are not very good at writing clean code. Including (especially?) seniors who think they write the best code on their team. The code you're having the juniors dig through to tweak/maintain is probably terrible code that should not be used as a shining example of anything good. They're more likely to pick up someone else's bad habits than learn something useful.

It took me a very, very long time to realize that it's simply a matter of fact that no two developers think alike, and that any set of developers could argue all day as to why each other's code is ugly, unmaintainable, etc. There are extremely few instances where one implementation of any problem is "better" or "worse" than another - we simply think differently. My code will always be "smelly" to you, and your code will always be "smelly" to me.

Junior developers must be permitted to write new code from scratch. Whether it hits production as-is, or goes through weeks of refactoring, it's a must. No developer ever improved by only reading and maintaining other people's code. I have never met a developer who feels at home maintaining someone else's rushed garbage. And 80%+ of the code we write is rushed garbage to attain the 3 week mandatory deadline handed down by management even though we told them it would take 3 months.

There is a finite amount you can learn by reading other people's code. You might find specific idioms you admire and adopt, but you will not - and probably should not - try to conform to other developers' methods.

Not to mention, forcing new recruits to deal with everyone's legacy garbage is a surefire way to turn them off the industry before they've even begun. Let them code a small new feature; then sit down and find out what they did well and what needs improvement; truly tangible issues, not the typical "that's not how it's done" - which really only means "that's not how I would have done it".

>> It took me a very, very long time to realize that it's simply a matter of fact that no two developers think alike, . .

I was part of ThoughtWorks interview process sometime back. In one of the rounds called Pair Programming, a senior developer worked with me on the given problem statement. I arrived at right solution, but he wasn't happy with the solution just because he didn't like the way I solved it. I came back and discussed the same solution with another senior developer and he liked the approach. However ThoughtWorks rejected me in the interview process.

I often wonder how pair programming is good (or even bad) in this context. How they can assume or think that two programmers going to solve the problem in "same" (or even ThoughtWorks "expected") way!

>> How they can assume or think that two programmers going to solve the problem in "same" ... way!

It takes a lot of restraint and stepping back from being in "first-person developer mode" to understand that someone else's unique approach is quite likely valid. I purport to be able to do so but I still find it incredibly difficult to ignore my brain's initial instinct to start pointing out the supposed flaws in someone else's structure, when the simple fact is my own code for the same problem would probably be filled with the same holes - just in a different form.

Honestly, there are only a few metrics that really matter when it comes to quality code:

1. Does the code accomplish the task it's supposed to? I mean really, this is practically the only thing that really matters in most cases. Simply: if deployed, will it work?

2. Are there no glaring security problems with the implementation?

3. Does the code not excessively overuse resources (cpu, memory, network/system calls, etc.)? Real excess beyond what is reasonable, not micro-optimizing.

4. Is the code not a complete mess? No serial use of copy/paste, crazy spaghetti mess, or inability or blatant refusal to follow basic coding standards?

That's it. Deploy that shit, and move on to the next problem. ;)

This is exactly what I was thinking! The points that were written is just as what I had in mind. But I guess still your missing one important point on testing. The code should work if deployed, but at the same time, we need to have through testing for the same.

I always start with reading test cases rather than source code directly. Thats the way it should be (IMHO).

After experience with several junior developers I plan to do the following to train the next one. First, let them solve an isolated problem in our code base. At pull request step comment excessively (this is what inevitably happens with all junior developers, the PR is so huge that GitHub chokes on it). Finally, pair them with a senior developer to solve the issues raised in the PR, rather than letting them fix them alone and engage in an endless loop of commits and comments.

I agree - you very much need to learn the rules first, before you go and break them

This is really a good idea. I have seen this happen with several teams in my organization.

I've been the other side of this as part of the interview process.

One person we were interviewing solved a problem pretty much exactly opposite to the way that we (and every other candidate) had solved it.

At first glance it simply looked wrong, but after a discussion with the candidate the strengths of the solution became apparent.

Happy to say they got the job, and ultimately turned out to be one of our best hires.

Your advice here probably applies more to beginner programmers where the goal is to prevent them from just copying/pasting code and following bad practices. It's a good thing for them to learn to write things from scratch. I've been programming for a while and I've felt for a long time like my skills kind of plateaued. Writing things from scratch and reading a lot about design principles haven't really helped me improve at all. But lately I've started to read code, really read it to understand what it does and this has vastly improved my skills.

> There is a finite amount you can learn by reading other people's code. You might find specific idioms you admire and adopt, but you will not - and probably should not - try to conform to other developers' methods

From my own experience I disagree with this since reading other people's code has helped me improve a lot. I've noticed that I am so much more creative and intuitive about good software design when I go to write code now and I believe it is credit to reading code everyday

As much as this is mostly true, its not always true... I've met at least 3 developers in my career i consider to write very good code, often better than my own... and a small handful i consider 'not-shit' and 'employable'...

The vast majority are just shit though. That was a hard lesson to learn. You want to give people the benefit of the doubt, but the industry is full of people who have learned nearly nothing in their careers compared to a really good grad who has never worked anywhere but has raw talent and good problem solving skills.

I'm hoping there's a way to teach them problem solving BEFORE they learn to code... I feel like it should be a prerequisite to enrolling in the bootcamp. I don't remember how I learned it, but it certainly wasn't reading other people's code at my first job.

Some people can be taught to write code, however far fewer can be taught to or have the natural ability to problem solve. This is the 'art' aspect behind software development that I feel the 'teach everyone to code' approach overlooks. With any creative field there is a huge amount of 'prior art' that exists and that is also constantly evolving, and the more of this you are at least aware of or - better still - capable of reproducing, the better you will be able to express yourself / problem solve with software.

I hope I am not alone in feeling that looking at the code of a well-engineered and well-structured project can be quite the artistic-appreciation experience, and that this experience always leaves you with some piece of knowledge and understanding you didn't have beforehand.

I know that I learned the basics of chaining things together to get an effect by experimenting on my own in QBasic; basic graphics and audio were super easy, so I could also experiment with the difference between internal data state and how to represent that state.

When I started a directed education, learning new programming concepts always expanded the set of problems that I could solve. Learning how to reason through them didn't come separately, it came through writing programs of increasing complexity over time.

Before learning any meaningful amount of programming, I was introduced to the idea of examining the capabilities of your available tools and using them to find creative solutions...with adventure games.

I would consider a curiosity for exploration and experimentation to be central requirements to become a problem solver (at least through the path that I did). Start with that general mindset, present a world for them to explore, introduce them to the tools they can do it with, and there's no way to stop them from that point on.

I don't really know of anyone who learned problem solving with a computer before they learned to code. Supposedly Dijkstra, but that man thought computers cheapened computer science.

I feel like there's so much intrinsic to the code to solve the problem though, like how the debugger works, git bisect / git blame to determine where an issue might have arisen, commenting out lines of code and checking if they cause a particular issue, etc.

I don't think I learnt about problem solving in the abstract, it was more about specific applications of problem solving in the programming world.

Someone gives you a one paragraph description of a feature... I assume you don't immediately open up the debugger and start git bisecting... I'm talking about the things that happen immediately after being presented with a problem, and before you start typing code.

Just to leave some suggestions of puzzle games that are little hidden gems and that provide great logic thinking training. IMO they should be played in the order below:

1) Blockly Maze game (free) (https://blockly-games.appspot.com/maze?lang=en)

2) Jelly no Puzzle (free) (http://qrostar.skr.jp/index.cgi?page=jelly&lang=en)

3) Human Resource Machine (paid) (http://tomorrowcorporation.com/humanresourcemachine)

I agree on the puzzle games: also, get them on Zachtronics games: Spacechem, namely.

Reply on news.ycombinator.com