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

What does it take to be a good programmer?

qristin.wordpress.com

Post reply on HN
Print view View original

91–100 of 107 posts

Re: What does it take to be a good programmer?

#91

Post by randomdata »

AlotOfReading wrote: post #67
bob1029 wrote: post #60

Earlier quoted context omitted.

This is our stance too. Even within the "batteries included" aspects of the .NET6 framework, we insist on doing certain things our way. Some of the biggest examples being AspNetCore logging and the JSON-style configuration abstractions. We completely rip this out and do it in code-time our way. I cannot account for the exact number of hours we wasted trying to do [x] the 'official' way only to be burned at deployment…

Reinventing the wheel can also lead to difficult-to-find bugs that explode years down the road. Yeah, you could reimplement the parts of zlib you need in a couple hours, but just use zlib, even if it's a core part of your functionality. However, as an industry we don't have a great way to know what is or isn't reliable. I've started publishing component datasheets with my utility libraries because that conveys the so…

> However, as an industry we don't have a great way to know what is or isn't reliable.

I'm not sure it matters. You can assume it will be as reliable as your own buggy code that you wrote yourself. The more important question is how maintainable or replaceable is it. Once you include a dependency it becomes your code to maintain, so it had better be something that you're comfortable jumping in and getting your hands dirty with if need be.

Re: What does it take to be a good programmer?

#92

Post by yetihehe »

solardev wrote: post #87
ChrisMarshallNY wrote: post #45

Earlier quoted context omitted.

> does not reinvent things which are not necessary to reinvent. This is one of those "eye of the beholder" things. If I had a quarter for every time I've heard "That's a solved problem," with a reference to a dependency, somewhere, I'd be a rich man. I tend to really avoid external (not written by me) dependencies, because I have had many problems with other people's code. Fixing someone else's badly written open-sou…

Yikes, I think this is how teams end up with "we should just rewrite this whole thing because the guy who wrote it liked doing things his own nonstandard way and nobody else can understand it once he left". Clever code that reimplements common packages just because one person thinks it's better for their particular use case might seem like a flex when you write it, but it's a pain in the ass for everyone after you...…

Good programmers know when to rewrite and when not from experience.

> Clever code that reimplements common packages

Common packages are typically not rewritten by good programmers.

Re: What does it take to be a good programmer?

#93

Post by ChrisMarshallNY »

solardev wrote: post #87
ChrisMarshallNY wrote: post #45

Earlier quoted context omitted.

> does not reinvent things which are not necessary to reinvent. This is one of those "eye of the beholder" things. If I had a quarter for every time I've heard "That's a solved problem," with a reference to a dependency, somewhere, I'd be a rich man. I tend to really avoid external (not written by me) dependencies, because I have had many problems with other people's code. Fixing someone else's badly written open-sou…

Yikes, I think this is how teams end up with "we should just rewrite this whole thing because the guy who wrote it liked doing things his own nonstandard way and nobody else can understand it once he left". Clever code that reimplements common packages just because one person thinks it's better for their particular use case might seem like a flex when you write it, but it's a pain in the ass for everyone after you...…

Well, it's kind of too bad, that everyone seems to have such terrible confidence in their own abilities.

There's a lot of things that I'm not good at, and one thing that experience has taught me, is to own that.

But there's also a fair bit of stuff that I'm really quite good at; above average, even.

If I write something, it tends to work pretty well. If someone else does a better job than me, I'm happy to use their stuff, but I have higher standards than "Ooh, shiny!". I won't use just anything, and "Everyone else uses it!" is not really the most heavily-weighted coefficient in my calculation.

I invite people to see for themselves[0]. I have an enormous library of work out there. I don't give a damn whether or not anyone else wants to use it. I am my own best customer. I write code that I want to use, and I use that code. I have extremely high standards, and I insist that my work meet my standards.

I find it fascinating that folks are happy to cast aspersions on me and my work, without checking for themselves.

[0] https://github.com/ChrisMarshallNY#browse-away

Re: What does it take to be a good programmer?

#94

Post by gniv »

I think I understand where OP is coming from. We are still in the wild-west era of software development and most programmers are like pioneers -- few rules, learning as they go, etc. I agree that as the domain matures we will see different types of people become programmers, and the job itself will change to something more conventional, but more stable too.

Re: What does it take to be a good programmer?

#96

Post by celdon25 »

solardev wrote: post #87
ChrisMarshallNY wrote: post #45

Earlier quoted context omitted.

> does not reinvent things which are not necessary to reinvent. This is one of those "eye of the beholder" things. If I had a quarter for every time I've heard "That's a solved problem," with a reference to a dependency, somewhere, I'd be a rich man. I tend to really avoid external (not written by me) dependencies, because I have had many problems with other people's code. Fixing someone else's badly written open-sou…

Yikes, I think this is how teams end up with "we should just rewrite this whole thing because the guy who wrote it liked doing things his own nonstandard way and nobody else can understand it once he left". Clever code that reimplements common packages just because one person thinks it's better for their particular use case might seem like a flex when you write it, but it's a pain in the ass for everyone after you...…

> Yikes, I think this is how teams end up with "we should just rewrite this whole thing because the guy who wrote it liked doing things his own nonstandard way and nobody else can understand it once he left".

I’d be willing to bet there’s more to the story in nearly every case. The non-standard way is often a deliberate choice to attempt to optimize for output, given unpredictable and unrealistic deadlines.

Then it proves futile when, for instance, the goalposts are moved again, and the last 25% of the implementation has to get rushed through. That’s when it turns into a pile of shit, and that’s when the person decides to leave. But not because of the deadline, but because of the incessant complaining, doubting, and negativity toward this developer, who got praise elsewhere for actually innovating. That’s why you hired him after all.

Nobody else apparently stepped up to help deal with the situation before it became a problem, hence the victimization. Companies like that are going to have a culture of finger-pointing and blame-throwing. Never taking responsibility for a situation they created. Problem-solvers need not apply.

This is how industries, not teams, fail. Good programmers know when to quit the rat race. Or they know how to choose companies that follow the golden rule. Take care of your people and they will take care of you.

But if someone is actually doing it to “flex”, they’re clearly not that experienced, in which case it’s also the company’s fault for giving them that much technical authority.

Re: What does it take to be a good programmer?

#97

Post by lowercased »

celdon25 wrote: post #96
solardev wrote: post #87

Earlier quoted context omitted.

Yikes, I think this is how teams end up with "we should just rewrite this whole thing because the guy who wrote it liked doing things his own nonstandard way and nobody else can understand it once he left". Clever code that reimplements common packages just because one person thinks it's better for their particular use case might seem like a flex when you write it, but it's a pain in the ass for everyone after you...…

> Yikes, I think this is how teams end up with "we should just rewrite this whole thing because the guy who wrote it liked doing things his own nonstandard way and nobody else can understand it once he left". I’d be willing to bet there’s more to the story in nearly every case. The non-standard way is often a deliberate choice to attempt to optimize for output, given unpredictable and unrealistic deadlines. Then it p…

> I’d be willing to bet there’s more to the story in nearly every case. The non-standard way is often a deliberate choice to attempt to optimize for output, given unpredictable and unrealistic deadlines.

Yeah... I hit this... A lot, in the past couple of years. "just get it out, we'll polish it later". It was... primarily me in dev (I was doing about 90% of the app code), and there was never enough time to catch up. I've moved on, and there's now ~3 people, and they've been given more time and ability to reset schedules and... now it's all "why was this done so poorly? this is garbage", etc. I've pointed to my many messages asking for things to slow down, schedule more time, etc. Always a "later", and now that the personnel have changed, and there's "more time" for everything... most of what I did looks bad. I was the only one writing tests - left them with 500+ tests, some documentation and action/decision log docs - but no one looks at it. "This is bad". Well... sure, but it's tested, and you now can refactor, vs rebuilding from scratch (which... I'd lobbied to do 2 years earlier, before building on top of the very shaky MVP).

Re: What does it take to be a good programmer?

#98

Post by GoblinSlayer »

ChrisMarshallNY wrote: post #71
AlotOfReading wrote: post #67

Earlier quoted context omitted.

Reinventing the wheel can also lead to difficult-to-find bugs that explode years down the road. Yeah, you could reimplement the parts of zlib you need in a couple hours, but just use zlib, even if it's a core part of your functionality. However, as an industry we don't have a great way to know what is or isn't reliable. I've started publishing component datasheets with my utility libraries because that conveys the so…

> However, as an industry we don't have a great way to know what is or isn't reliable. That's the rub. Your zlib example is one of the "Platonic Ideal of Quality Open Source" libraries. Using that is a no-brainer. Any suggestion of rating/licensing/qualifying open-source projects, is met with ... resistance ...

It's still a full plate of old good C spaghetti https://github.com/madler/zlib/commit/eff308af425b67093bab25...

Re: What does it take to be a good programmer?

#99

Post by GoblinSlayer »

dc-programmer wrote: post #78
ChrisMarshallNY wrote: post #61

Earlier quoted context omitted.

Not really. I'm pretty good at what I do. Feel free to see for yourself: https://github.com/ChrisMarshallNY#browse-away Most of those repos are dogfood.

What you are saying absolutely makes sense to me for domains like device drivers. I think it becomes a lot more questionable when your coworker wants to write their own JSON parser or HTTP server for use on a commodity x86 linux box. It’s an incredible waste of resources and a major security hazard too boot.

I wrote JSON parser and http client for commodity platform, and they are 100 times safer than everything else, partly because they aren't overengineered beyond all reason.

Re: What does it take to be a good programmer?

#100

Post by GoblinSlayer »

ChrisMarshallNY wrote: post #3

> You need to be really smart and have a scientific mindset. Most importantly you need to love learning new things. I'm not so sure that these are required . I think they are more akin to "commonly found characteristics." Especially the "scientific mindset" part. I have a disciplined mindset, but I suspect most scientists would take issue with me, calling it a "scientific" mindset. In my experience, being a good prob…

Stubborn problem solving isn't always good. A problem can be solved in many ways, some of then can lie in the realm of program architecture or even product strategy. If your solution conflicts with them, it will be thought of as narrow sighted.
Post reply on HN