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

Skills Poor Programmers Lack

justinmeiners.github.io

Post reply on HN
Print view View original

111–120 of 211 posts

Re: Skills Poor Programmers Lack

#111

Post by quadcore »

Most programmers work in passes, and don't write everything in one shot. But a common mistake I see is not doing enough passes still. Programmers jump on making polished commits they can show off to their peers.

Instead, what should be use more often is what I would call "postit commits". Simple strokes of code that are certainly not final (if any code can be final) but achieve a purpose. Their postit nature makes it very easy to change. Those commits still need to point in the right directions though because they may stay here for a while (think 15 years). As long as they aren't hurting the customer or the codebase (like a supposedly-temporary hack, even though those are sometimes required), then it's all fine, a program is never finished anyway.

Working with more passes allows you to think more at every step and shape a solution that's more efficient. For example, take a piece of code that's too slow for the requirements and for obvious reasons. Don't necessarily jump on optimising it right away. You may find later that you will finally get the whole subsystem in which that piece of code is included better by using another more powerful idea. And when you come up with that new idea, the only thing that will stand in your way is "postit commits". You can change things now because you're not facing polished ones. You can change things now, not in 10 years when you find out every one of your competitors has finally implemented that idea, in which case you would take the cost of a full rewrite.

This is essentially how you do things well from scratch (and by extension, how you do anything well with code). Keep postits as long as you can, because it's a better strategic position. Only harden a solution when you can't give it more time or because it just hardened itself with cool ideas. At the end of the day, you will win time, if you worry about that. You will crush your competitors even. They will have 3 times more code with bad solutions, you will have 3 times less code with all the super cool stuff and nice subtleties (it doesn't always play out like that, but often enough).

Re: Skills Poor Programmers Lack

#112

Post by aastronaut »

atmosx wrote: post #20
arwhatever wrote: post #16

The most lacking skill that I tend to see is an inability to think in types, and to design software accordingly. Too many software developers never progress beyond primitives and basic control structures - I call them Int, String, and For Loop Developers. Second biggest issue I see is failing to incorporate our cognitive shortcomings into code design, assuming that you'll remember these dozens of little details from…

Can you give a clear example on “thinking in types” approach ?

Not GP, but the book 'Domain Modeling Made Functional' does explain advantages in modeling with types quite well.

Re: Skills Poor Programmers Lack

#114

Post by _old_dude_ »

crimsonalucard wrote: post #78

>I believe OOP and relational database get a lot of flack because programmers tend to be bad at design, not because they are broken paradigms. OOP has Fundamental and Intrinsic problems that can be described in a very concrete way. If you believe OOP gets a lot of flack just because programmers are bad at design, then you are the one that is also bad at design. I will say this, OOP is bad for many and most design pro…

you get it wrong :)

> Objects are actually arbitrary mixtures of lower level primitives: functions and data.

Nope, everything is an object, numbers, array, function, etc, are objects.

Objects allow you to describe user-defined data by composing objects

  address1 = Address { street: "..." }
  address2 = Address { street: "..." }
  john = Person {
           name: john,
           addresses: [address1, address2]
         }
Methods are functions biased toward an object, which allows polymorphism, so you can abstract over data

  function f(data) {
    data.add("foo");
  }
works for every data that provides a method "add".

so OOP is complementary to function.

That said, OOP has several flaws: - at some point someone decides that OOP was about inheritance or prototype chains but those mechanisms are more bad than good. - existing mainstream languages tend to favor mutable objects by default which leads to bugfests.

Re: Skills Poor Programmers Lack

#115

Post by coldtea »

adamparsons wrote: post #10

Kinda frustrating that an article calling out where programmers fall short was a non-responsive document that was almost unreadable on mobile. Mildly ironic?

No, mildly unrelated and orthogonal. Not everybody cares for their website to be read well on mobile (I, for one, don't), and not everybody who runs a blog has/wants control over the posting environment (they just pick an engine and them and be done with it -- if the readers find their work valuable enough, they can spend some effort to read it).

Re: Skills Poor Programmers Lack

#116

Post by MisterTea »

cjfd wrote: post #77

In all fields there is a minority who are not very good at what they do. I think, though, that in programming that minority might actually be a majority. The thing is, if you are a poor plumber who causes floods in peoples houses you are not going to be in business for a very long time. In programming there seems no such discipline because it actually takes somebody good at programming to perceive the difference betw…

> The thing is, if you are a poor plumber who causes floods in peoples houses you are not going to be in business for a very long time.

That might be true if the pipes leak after repair or installation. But what if the job holds up long enough to allow the plumber to avoid responsibility?

Same with software. It has to just work well enough to appear functional and for long enough to allow the developer to quickly shed responsibility and put distance between them and the customer. Then blame them for the error and force them to pay for support.

Dealt with an ERP system like that. Didn't matter how fragile or crappy their system was, you had to pay tech support to fix their bugs (windows 7 updates broke it frequently ...) Twice it nuked its own DB and had to restore from backups. We had to pay tech support to tell us that. They're still in business. Once they got you on the hook and their system becomes the companies lifeblood then you tend to eat the crap sandwich and pay up. Then if you leave a bad review they sue you for defamation.

Re: Skills Poor Programmers Lack

#117

Post by coldtea »

d_burfoot wrote: post #58

> I believe OOP and relational database get a lot of flack Who gives relational databases flack? The RDBMS and SQL is the cleanest, simplest, and most productive technology stack I've ever used.

>Who gives relational databases flack?

Tons of people, it was especially a thing back in 2005-2015 with the ORM craze (and the supposed "impedance mismatch between relational and OO") and then the NoSQL craze (and how schemas and relations are a thing of the past).

Re: Skills Poor Programmers Lack

#118

Post by robohoe »

klenwell wrote: post #14

As an addendum perhaps to the Organize and Design Systems section, I'd propose including mise-en-place as it applies to project maintenance and the development environment. This centers on tooling and documentation, especially the README. I want a README that gets me set up and running as quickly and in as few steps as possible. Recently I needed to test out some stuff one of my teams was working on. It was a somewha…

It would also help if folks read READMEs. I write a lot of them for my projects at work. Most are detailed but also have a quick setup section in the beginning. Unfortunately people still don’t read them and if they do they miss steps specifically spelled out within markdown formatted code blocks.

Re: Skills Poor Programmers Lack

#119

Post by rounce »

kevsim wrote: post #101
r4mbini wrote: post #97

> In JavaScript, this is often indicated by new Promise inside a .then(). I have found myself doing this sometimes, why is it considered bad practice?

I guess because inside of a then() you can simply return the success case and throw the error case, no need to create a new Promise and call the resolve/reject functions.

Was trying to think of exceptions to this when I read and and could only think of one: When you need to wrap a callback API with unusual callback arguments, where a `promisify` like helper won't work. Then again, I still feel the wrapping function should be defined outside of the `then`, as it feels like this is a separate utility to the work being done in the Promise chain.
Post reply on HN