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

81–90 of 125 posts

Re: How I Became a Better Programmer

#81

Post by Chris2048 »

collyw wrote: post #49
couchand wrote: post #30

Earlier quoted context omitted.

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.

Aren't style guides supposed to help write code that is more standard in style, and hence easier to read - because your brain will become accustomed to that style.

And PEPs cover many things.

Re: How I Became a Better Programmer

#82

Post by sillysaurus3 »

sheepmullet wrote: post #76
sillysaurus3 wrote: post #69

Earlier quoted context omitted.

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…

The company prior to my last had 50,000 employees. We were still able to design and implement a solution for a core aspect of the division. I had to push in the direction of Python + Redis, but when people saw the results, the higher-ups listened to our team.

I think you're right that if a system is massive, there won't be many major changes to it. But that's true regardless of who has authority. It's always possible to solve smaller business problems with self-contained projects that can then be integrated into the larger system. But not if an environment is set up to prevent someone from doing this by forcing them to work within the constraints of the existing monolith.

(It's possible to do this without creating a microservice, in some cases. The important part is simply to be allowed to experiment with alternate solutions, as long as it's not interfering with your main duties.)

Re: How I Became a Better Programmer

#83

Post by dplgk »

BurningFrog wrote: post #31
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!

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.

1. That's a good way to break it.

2. Typically there is not extra time given to cleanup code, write docs and unit tests.

Re: How I Became a Better Programmer

#84

Post by weavie »

k__ wrote: post #68

> Find people who inspire you, but don't idolize them. Luckily this is rather easy in the JavaScript world, haha. Many good devs have bad attitudes, which makes it a bit harder for junior devs to value their skills, but it prevents them from being idolized too much. Also, I always think it's a good sign if devs I look up to said stuff I found bad, so I know I still see them as humans and not as infailable idols. > Do…

> I got a big book on HCI research of the last 50 years or so and I always find nice solutions for my problems there. Since many of the web and mobile problems have already been solved with experiments on research devices that never went mainstream.

Please share, which book is this?

Re: How I Became a Better Programmer

#85

Post by [deleted] »

k__ wrote: post #68

> Find people who inspire you, but don't idolize them. Luckily this is rather easy in the JavaScript world, haha. Many good devs have bad attitudes, which makes it a bit harder for junior devs to value their skills, but it prevents them from being idolized too much. Also, I always think it's a good sign if devs I look up to said stuff I found bad, so I know I still see them as humans and not as infailable idols. > Do…

[deleted]

Re: How I Became a Better Programmer

#87

Post by scarlac »

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…

My personal recommendation would be to learn and understand how pointers work. In the years I spent dealing with C and C++ I can trace many of my major learnings back to how pointers work. You can't really understand pointers until you understand how memory is managed, including all the pitfalls and performance tricks that comes along.

Re: How I Became a Better Programmer

#88

Post by AstralStorm »

tshannon wrote: post #77
fauigerzigerk wrote: post #59

Earlier quoted context omitted.

>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.

And you end up with the 60+ year old TODO this way. Or lack proper reason comments (the why) and end up in a gaggle of legacy code.

My rule is simpler: never write instant legacy code. If it feels like something you won't understand a month later, it likely is legacy code.

If it reads badly (and I'm not talking about this or that brace or whitespace choice), then it also provably is in that category.

Re: How I Became a Better Programmer

#89

Post by cname »

BurningFrog wrote: post #31
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!

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.

I think a good metric for "advanced/senior programmer" is "writes reasonably clean code from the start". Not perfectly clean, but reasonably well-architected--at least easy to read and change. At a certain point, there's really no good excuse for starting out with a big ball of mud.

Re: How I Became a Better Programmer

#90

Post by AstralStorm »

sriku wrote: post #25
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…

The note about DRY didn't sound like a mandate to ignore it entirely and "duplicate freely". As you said, duplication is a way to ratify that a common pattern exists first before putting something in place that captures the pattern. Many young programmers try to anticipate these concepts and end up with some form of over-design. The goal of DRY is not so much to avoid duplication, but to figure out useful concepts in…

If you do not anticipate concerns and rely solely on bottom up design, you are guaranteed to require expensive rewrites. Plural. It is also as trivially easy to end up with bad abstraction bottom up add top down, usually by not taking measures to uncouple components (also known as leaking implementation in abstraction)

Properly anticipating issues takes experience.

Post reply on HN