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

111–120 of 125 posts

Re: How I Became a Better Programmer

#111

Post by sheepmullet »

sillysaurus3 wrote: post #82
sheepmullet wrote: post #76

Earlier quoted context omitted.

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…

How big was your team? How big was your project (kloc + timeframe)? How many other teams did you have to integrate your solution with? What effort did they have to put in to consume your work?

Again I think we are simply dealing with different scales of systems.

Re: How I Became a Better Programmer

#112

Post by cname »

ianbicking wrote: post #100
cname wrote: post #89

Earlier quoted context omitted.

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.

This is a reasonable expectation when writing something the developer understands and has experience with, with an architecture that seems self-evident early on. Lots of problems are like this. But when I see developers with the self-expectation of clean code take on a task where the architecture is not self-evident, where the architecture probably won't be right the first time, then they often freeze up. Or they mov…

I've definitely been there fiddling around with abstractions or whatever. I guess I think you're really starting to get good when you see yourself doing that kind of thing and make yourself stop and figure out what the real goal is and how to proceed. E.g., maybe stop banging on the keyboard and draw a picture, work through an example, talk to the client, etc.

Re: How I Became a Better Programmer

#113

Post by sriku »

AstralStorm wrote: post #90
sriku wrote: post #25

Earlier quoted context omitted.

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.

Thus far, "properly" has been elusive - I.e. we know it when we see it, but not beforehand​. It has been easier to instruct people to look at past concerns in similar projects and tick off which ones are relevant based on current constraints and requirements. So it is not a one-time task to set the "properly" needle right, but a continuous one to keep adjusting it as the cases evolve.

The way abstractions are usually laid out is by trying to generalize a concept, usually along simplistic lines without attempting to substantiate it. Beta abstraction provides a substantiatable route which could involve a bit of repeating before the abstraction surfaces. For example, the Pixar cars don't form a class hierarchy with a "car" base class - there is only one class "car" and the variety is generated by configuration (need to pull up ref for this, as I read this long ago). This may not be an obvious step for someone not in the domain.

Re: How I Became a Better Programmer

#114

Post by kwhitefoot »

BurningFrog wrote: post #109
mythrwy wrote: post #107

Earlier quoted context omitted.

They never give me the time for items #2 and #3. As soon as it works most clients and bosses figure "done".

How does that work exactly? Why can't you just keep working until you consider your task done?

Are you working as a developer? If so, how do I join your team? In my life as a developer I have deadlines that are set by customers and no amount of explanation that I need another week to make the code bomb-proof will shift them.

Re: How I Became a Better Programmer

#115

Post by antoaravinth »

>> Take on big projects. Get uncomfortable.

To add few more points on this, work on side projects. I have to tell, how a side project can help you. For example, I was very comfortable using React in my project. I thought of building a simple preview container (for different sizes from desktop, mobile, tablets), where user can drag and drop few components, position them etc.

I'm in the initial phase of this and guess what, its really helpful. Making you uncomfortable at times (as in this case for using React to position components on the fly, which I had never done before) helps a lot.

Re: How I Became a Better Programmer

#116

Post by jondubois »

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…

It's not necessarily about being a generalist. You can move between different companies within the same industry and get highly specialized knowledge within a specific domain. Going through a few companies trains you to think creatively and consider more different approaches.

Re: How I Became a Better Programmer

#117

Post by k__ »

weavie wrote: post #84
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?

the human computer interaction handbook

by Julie A. Jacko and Andrew Sears

Re: How I Became a Better Programmer

#118

Post by Chris2048 »

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…

While it can be nice to learn at work, that isn't the prime aim: the main reason to work is to make money. If you are productive, enjoy it and save your mental energy for after-work projects.

Granted; there are some things that require so much time you need to do it at work to really get the grasp of it, but this isn't everything.

Re: How I Became a Better Programmer

#119

Post by Chris2048 »

JCDenton2052 wrote: post #70

" (This also applies to the DRY principle. Don't worry about it so much. Feel free to duplicate.)" The sort of advice followed by programmers when building systems that will accumulate heavy technical debt that someone else will eventually have to sort out. You will not become a better programmer this way.

application of DRY can also accumulate technical debt.

The main thing is communication - duplicate, but put comments in both places regarding the duplication so they can be merged if they haven't diverged after time.

This is also why I dislike "no comments in code" principles - communication is key, and there are some things only plain English can convey; If all your comments are code, you aren't communicating enough!

Re: How I Became a Better Programmer

#120

Post by Chris2048 »

bobwaycott wrote: post #40
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…

I met James around 9 years ago when I was first starting out in professional development, before he eventually joined Mozilla. I inherited more than one massive project from him, and I'd like to assure you he did not actually ignore the form of his code, nor did he avoid improvements that paid huge dividends. I've always been rather OCD about DRYness, and I never had cause to complain about the quality of his work, n…

> I've seen many junior devs get so worried about the quality of their code, and how they should do things

TBH, junior devs are often hammered constantly throughout training about this stuff. They are drilled on design patterns before having even coded anything significant.

It's not surprising they can only breathlessly parrot software principles when they begin..

Post reply on HN