Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How I Became a Better Programmer

jlongster.com

Post reply on HN
Print view View original

41–50 of 125 posts

Re: How I Became a Better Programmer

#41

Post by Vinnl »

couchand wrote: post #30
Permagate wrote: post #14

Earlier quoted context omitted.

> I also strongly disagree with the suggestion that you should ignore the form of your code. Code is read many, many times more than it is written, so improvements to your own and your teammates' understanding can pay huge dividends. While he explicitly said to ignore fluffs, he followed it up with `Another way to say this is "use your time wisely"`. So I interpreted it as to just not spend too much time on fluffs, r…

Simply using the term "fluff" to describe the form of code shows a lack of respect that I find deeply troubling. Those that pay little attention to code style, form, names of things, etc. (including those who rely on the tooling to fix it for them) tend to miss other, arguably more critical, things. Sometimes, but not always, this happens because those errors are lost in a soup of poor formatting and copy-paste repet…

But then again, actually writing a code formatter does show quite some respect ;)

Re: How I Became a Better Programmer

#42

Post by nallerooth »

couchand wrote: post #11

There's a lot of value here, but I have to raise concerns about a few things. First, the title: written in the past tense makes it seem like he believes the journey is complete. The article itself doesn't convey that message, fortunately. But I think it's worth noting that a critical skill for a professional is constant education - don't be satisfied that you're already "better", get better every day. I also strongly…

My interpretation was more like "do not focus too much on the form of your code, while you are figuring things out". Which I think is decent advice.

The classic line "Make It Work, Make It Right, Make It Fast"[1] may have communicated this concept in a better way (with each step explained).

[1] http://wiki.c2.com/?MakeItWorkMakeItRightMakeItFast

Re: How I Became a Better Programmer

#43

Post by tomjen3 »

Fifer82 wrote: post #39

I also have 10 years experience but I am in the same job because I can't defeat recruitment agencies. If today a new Framework, let's call it "Framework9" is announced, all jobs will instantly want 3 years experience, and 4-5 years experience of all other known frameworks, preferably in all languages, and preferably a designer who is a master of photoshop and CSS, with a long history of blah blah blah blah I am reall…

And I want a two dollar Ferrari, but realistically i take what I can get. Recruiters will have to do to.

Re: How I Became a Better Programmer

#44

Post by CaRDiaK »

Fifer82 wrote: post #39

I also have 10 years experience but I am in the same job because I can't defeat recruitment agencies. If today a new Framework, let's call it "Framework9" is announced, all jobs will instantly want 3 years experience, and 4-5 years experience of all other known frameworks, preferably in all languages, and preferably a designer who is a master of photoshop and CSS, with a long history of blah blah blah blah I am reall…

In my experience that's often sign of either a job position where they don't really know what they want, or a recruiter casting a wide net trying to catch people with a bit of each on their resume. Playing keyword bingo. I've had much more success by looking around on the likes of linkedin / twitter to find the good recruiters. Single people with their own shop or ones within an org. The ones who seem to be well recommended or seem to know their game. Approach them personally, make friends with them, get to know them. Tell them you are bad at BS. Once they get to know you, they will go to their network. Let them do their job of finding you the position. Or, they will put you on their books for when a suitable one comes up. I find the quality of positions and work is much higher doing things this way. This took me a long time to work out too.

Re: How I Became a Better Programmer

#45

Post by jaredklewis »

Fifer82 wrote: post #39

I also have 10 years experience but I am in the same job because I can't defeat recruitment agencies. If today a new Framework, let's call it "Framework9" is announced, all jobs will instantly want 3 years experience, and 4-5 years experience of all other known frameworks, preferably in all languages, and preferably a designer who is a master of photoshop and CSS, with a long history of blah blah blah blah I am reall…

The bad news is that job descriptions are written in vacuums with no connection to reality.

The somewhat good news is that job listings are not a great way to find jobs anyway.

I have and have known many others that have gotten jobs they did not meet the description for at all. Just a matter of going out and meeting people. If you can meet someone face to face, they won't sweat the details in the job description. No bullshitting required.

Re: How I Became a Better Programmer

#46

Post by _pmf_ »

I think that a lot of the cognitive dissonance between what we think very good programmers do and what we ourselves do stems from the fact that the people whom we perceive to be very good programmers do greenfield projects and we non-rockstars are stuck having to maintain legacy applications, where there's a lot less room to be "very good"; mostly, it's a success to do this work for 2 weeks before giving up.

Re: How I Became a Better Programmer

#47

Post by chubot »

markwaldron wrote: post #16

Those that are complaining about this article: Care to share the experiences that made you a better programmer? Can you link to blog posts yourself or others made that we may find useful?

I've been doing the following for several years, and I think it's a good low commitment way of learning, i.e. there's a lot of bang for the buck.

1. Make a ~/git/scratch repository.

2. Whenever you see a code snippet in an interesting blog post, don't just read it. Copy it into a subdir of ~/git/scratch and run it. Write shell scripts to automate the process of running it. Prove to yourself on your computer that it works.

The first few times, it may be a little onerous. But eventually you will fall into a groove and it will take 60 seconds or less each time.

I don't promise to understand it on the first pass. Just the act of downloading it and running it gets it into your brain. Half the time you end up hacking on it anyway, and other times, you don't understand it, but when you see something related later, the light bulb will go off in your head -- "that's similar to something in my ~/git/scratch repo". And then you can go from there.

I don't know why but having a running code snippet really makes it feel "ready at hand" and you will learn faster. It somehow primes your subconscious. I feel like there are a lot of people who read Hacker News a bit passively, without retention.

Here's a good blog post along those lines, with code: http://journal.stuffwithstuff.com/2013/12/08/babys-first-gar...

-----

A much bigger commitment, but with correspondingly bigger benefits: I found helpful was to reimplement like 10 different things I use in maybe 500 - 1000 lines of Python. I like the new "500 lines or less" book [1] -- I was doing this 10 years ago!

Once you implement some class of program, you have a very good idea of how the "real" libraries you use are implemented. That helps you build better systems and write better code.

Examples: A template language, a pattern matching language, test framework, protobuf serialization, a PEG parsing language, Unix tools like grep/sed/xargs, an event loop library based on Tornado, a package manager, static website generator and related tools, a web server, a web proxy, web framework, etc.

In addition to writing something from scratch, I also find tiny code on the Internet and play around with it, like tinypy, OCamlLisp, femtolisp, xv6, etc.

[1] http://aosabook.org/en/index.html

Re: How I Became a Better Programmer

#49

Post by collyw »

couchand wrote: post #30
Permagate wrote: post #14

Earlier quoted context omitted.

> I also strongly disagree with the suggestion that you should ignore the form of your code. Code is read many, many times more than it is written, so improvements to your own and your teammates' understanding can pay huge dividends. While he explicitly said to ignore fluffs, he followed it up with `Another way to say this is "use your time wisely"`. So I interpreted it as to just not spend too much time on fluffs, r…

Simply using the term "fluff" to describe the form of code shows a lack of respect that I find deeply troubling. Those that pay little attention to code style, form, names of things, etc. (including those who rely on the tooling to fix it for them) tend to miss other, arguably more critical, things. Sometimes, but not always, this happens because those errors are lost in a soup of poor formatting and copy-paste repet…

I see a lot of article that tell you how to improve code, and they often seem focused in the wrong area. Python's PEP for example, I see the value in it, but you can follow that to the letter and still have a badly designed application and confusing code.

Re: How I Became a Better Programmer

#50

Post by collyw »

markwaldron wrote: post #16

Those that are complaining about this article: Care to share the experiences that made you a better programmer? Can you link to blog posts yourself or others made that we may find useful?

Not complaining about the article, but here are my thoughts.

Write and maintain your own code for a significant amount of time. When you see bugs repeating themselves you have no one to blame but yourself. If you come back to code that you have written a few months later and you can't make sense of it fairly quickly, its probably time to refactor that part. Think about the design up front and the implications of doing things that way or another way.

Post reply on HN