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

71–80 of 125 posts

Re: How I Became a Better Programmer

#71

Post by TeMPOraL »

sillysaurus3 wrote: post #54
jondubois wrote: post #52

My advice is that whenever you become confident/comfortable in your current work, that's when you have to change team or company. Whenever it gets easy, it means you have stopped learning. I agree with what was said about tools; it doesn't make you a better programmer to know all the latest ES6 features and frameworks. What makes you a better programmer is your ability to adapt and customize your approach to differen…

My advice is that whenever you become confident/comfortable in your current work, that's when you have to change team or company. Whenever it gets easy, it means you have stopped learning. I agree with what was said about tools; it doesn't make you a better programmer to know all the latest ES6 features and frameworks. It's tough to say. Given a choice between being a JS ninja capable of hammering out http://www.trac…

Offtopic, but I have to say - I love the site you linked. This should be a standard thing done about every politician in power.

Re: How I Became a Better Programmer

#72

Post by sillysaurus3 »

TeMPOraL wrote: post #71
sillysaurus3 wrote: post #54

Earlier quoted context omitted.

My advice is that whenever you become confident/comfortable in your current work, that's when you have to change team or company. Whenever it gets easy, it means you have stopped learning. I agree with what was said about tools; it doesn't make you a better programmer to know all the latest ES6 features and frameworks. It's tough to say. Given a choice between being a JS ninja capable of hammering out http://www.trac…

Offtopic, but I have to say - I love the site you linked. This should be a standard thing done about every politician in power.

It's the brainchild of Sam, Greg, Alec, and Peter. https://twitter.com/sama/status/822494523959877632

Greg is the JS ninja I was referring to. https://twitter.com/sama/status/822500368797966336

Re: How I Became a Better Programmer

#73

Post by omgno »

> Learn C - Just the basics, if you don't already. I think it's valuable to understand why everyone complains about it.

WHAT? C is beauty, C is art, C is clean and concise. What is this guy talking about? Nobody complains about C, it's about C++ they complain, you idiot.

Re: How I Became a Better Programmer

#74

Post by _petronius »

couchand wrote: post #27
richdougherty wrote: post #15

Earlier quoted context omitted.

Responding to your last two paragraphs... James's suggestions about ignoring code form, DRY, etc resonate with me because I'm someone who is usually inclined to spend too much time on those things. I consciously try to reduce the effort I put into those things and instead focus on trying to get the code to actually do something!

Thanks for providing your perspective here, I'd guess that he has a similar mentality, which is why he wrote that. In my (admittedly anecdotal) experience, devs who tend to overemphasize formatting and DRY are already self-aware about it, whereas those who give it far too little care and attention regularly shoot themselves in the foot by overlooking simple mistakes that get camouflaged in poor formatting and excessi…

I think this is a really good point. I am probably far too guilty of overemphasizing formatting etc., but by the same token, have seem the chaos that a lack of care in that department can cause, especially on big projects. Coming back to a big pile of code that someone else wrote, which is difficult to read or make sense of, six months after the fact to do maitenance is, like, top three things that make my professional life difficult.

Formatting, DRY, and good code organization don't solve business problems, but they do make solving those problems (and keeping them solved) a lot easier.

Re: How I Became a Better Programmer

#75

Post by SnowingXIV »

Learn C - Just the basics, if you don't already. I think it's valuable to understand why everyone complains about it.

When you say just the basics, what are you referring to? Syntax? Pointers? Dealing with garbage? I've got a vague idea about it, but never had to really do anything with it so I feel now is a good time to mess around with it.

Great read though, always a pleasure seeing James mentioned (someone that definitely inspires me).

Re: How I Became a Better Programmer

#76

Post by sheepmullet »

sillysaurus3 wrote: post #69
sheepmullet wrote: post #64

Earlier quoted context omitted.

What do you mean? The two best developers I know have spent 12 years at Microsoft and 6 years at Google respectively. What makes you think you need to switch jobs every 12-18 months to make a name for yourself? And what makes you think the best developers care about making a name for themselves?

We may be using different definitions of "best." In some companies, the best developers are the ones who keep their heads down, do what their told, and don't try to question authority, decisions, or direction. These traits are highly desirable precisely because people reliably do what their told. In other companies, creativity is considered an asset. Most of the important work done at my previous company was largely…

We are speaking past each other.

I'm not talking about "paying your dues".

It takes time to get up to speed and to build trust when you are performing high impact work on a medium-large project especially if you don't have prior domain knowledge.

> Most of the important work done at my previous company was largely completed by one very productive intern

> liberal in granting freedoms but also willing to fire someone if they turn out not to be able to deliver.

I suspect we simply deal with different sized systems.

The idea that an intern could do most of the important work implies you work for small companies.

In comparison my current project has ~90 devs.

Likewise you have this idea that you can quickly determine a good choice from a bad one. I'm still cursing design decisions I made 3 years ago that everyone thought were great at the time. If I had left after 6 months I would still be patting myself on the back.

Again that seems to apply better to small companies.

Re: How I Became a Better Programmer

#77

Post by tshannon »

fauigerzigerk wrote: post #59
BurningFrog wrote: post #31

Earlier quoted context omitted.

The time to clean up the code is when it already does what it should. That is: Make it pretty and readable and DRY once the code works. Until then my code can have several ugly and improvised things I've left for later.

>The time to clean up the code is when it already does what it should. I'm a bit skeptical of that as a general principle. I want code to be a consistent representation of my mental model of the solution at all times . I use code to help me think, remind me of my thinking and communicate with others. It's not just a series of commands that make a machine do something. As long as any ugliness is not in conflict with t…

Yep, I agree. I see it more as a list of priorities, not necessarily sequential steps.

1) Make it work 2) Make it maintainable 3) Make it fast

All three should be on your mind when developing something, but if you have to choose between 2 and 1, go with 1.

Re: How I Became a Better Programmer

#78

Post by [deleted] »

SnowingXIV wrote: post #75

Learn C - Just the basics, if you don't already. I think it's valuable to understand why everyone complains about it. When you say just the basics, what are you referring to? Syntax? Pointers? Dealing with garbage? I've got a vague idea about it, but never had to really do anything with it so I feel now is a good time to mess around with it. Great read though, always a pleasure seeing James mentioned (someone that de…

[deleted]

Re: How I Became a Better Programmer

#79

Post by anatoly »

SnowingXIV wrote: post #75

Learn C - Just the basics, if you don't already. I think it's valuable to understand why everyone complains about it. When you say just the basics, what are you referring to? Syntax? Pointers? Dealing with garbage? I've got a vague idea about it, but never had to really do anything with it so I feel now is a good time to mess around with it. Great read though, always a pleasure seeing James mentioned (someone that de…

I think most advice to "learn C" really aims to get you to learn how things work closer to the metal. What actually becomes of your code and data, broadly speaking, once your high-level language's interpreter or compiler have had their way with them.

So things like:

- viewing primitive objects, structs and arrays as blobs of bytes arranged between address X and address Y

- a pointer as an address of that blob. Understanding what it means to copy that blob vs. to pass around the pointer: calling by value/reference not in terms of the semantic effect, but in terms of what happens underneath.

- the stack and how it's typically used, esp. in recursion. Local vars vs. heap-allocated vars. How control flow leaves its trace on the stack. How arguments are passed and return values are returned.

- complex data objects viewed as blobs of memory pointing to each other vs. pointers. Concept of "owning" such a blob and how ownership is passed. Understanding how your language's runtime keeps track of the blobs if you don't have to, and what are common pitfalls.

- clear understanding of the difference between int8, int32, int64. Strings as null-terminated or counted arrays. Bitops.

"Learn C" is just a useful way to force you to internalize all of the above, because you can't properly "learn C" without doing that. But it's the above that helps you back in your favorite language. That, and perhaps the fact that C gives you a feeling what it's like when you can look at a line of source code and understand immediately what happens in the machine (broadly) when executing it. No hidden effects. C++ doesn't have that (constructors you don't know about when looking at the line, exceptions etc.) That "local clarity" isn't the most important thing in the world, but if you feel and appreciate it, perhaps you'll strive for local clarity back in your favorite language, too.

Re: How I Became a Better Programmer

#80

Post by gbersac »

chubot wrote: post #47
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 w…

I'll take a look at the "500 lines or less" book.
Post reply on HN