Skills Poor Programmers Lack • Hacker News Board

Re: Skills Poor Programmers Lack

#191

Post by munchbunny » Mon, Jul 22, 2019, 6:26 AM UTC

vorg wrote: post #161

apo wrote: post #73

The skills cited in the article are: 1. Understanding how the language works. Additionally understanding how the language infrastructure interfaces with the computer. 2. Anticipating problems. Prefer solid foundations over veneers that appear to get the job done. 3. Organizing and designing systems. Essentially, SOLID. Two things on this: First, bad code often results from conflicting goals. Moving goalposts and on t…

> the most valuable skill a programmer can have isn't technical, but rather social: empathy You should say "a programmer needs social skill as well as technical skills to be valuable". If a programmer doesn't have a basic aptitude for programming-like tasks, they won't be able to understand how the language works, anticipate technical problems, or organize and design systems. Until you've worked in a group that's fil…

"Social skill" and "empathy" are very different things. An awkward person can be empathetic. A charming person can be callous.

In fact, I'm even suspicious of people who say "the most valuable skill a programmer can have isn't technical, but rather social" because they often turn out to be aptitudinally-challenged programmers themselves.

In my experience the programmers who are saying that are usually engineering leadership. If you believe the endgame is becoming engineering leadership, then it's absolutely true that soft skills become more important.

While I don't agree that "social skills" are the most valuable skill for a programmer, I do sincerely think it is the most common reason why competent programmers hit an invisible ceiling in their careers. I've seen plenty of programmers who are technically talented and hardworking, but who get stuck in their careers at the junior end of "senior" because nobody wants to work with them no matter how right they are. If person A is right 90% of the time but nobody wants to deal with them, and person B is right 80% of the time and people are willing to listen, I would rather keep B over A because those junior developers who are running at 60% will turn into 80%-ers under B, but they'll stay 60% under A.

Re: Skills Poor Programmers Lack

#192

Post by orwin » Mon, Jul 22, 2019, 7:57 AM UTC

dodobirdlord wrote: post #155

userbinator wrote: post #106

Earlier quoted context omitted.

Yes, I'd call that "grouping related data (and functions, if you're using OOP) together"; no need to obfuscate the matter by saying "thinking in types". Incidentally, that's another thing about the difference between actually-skilled programmers and "pretenders": the former will always explain something in very simple terms, while the latter will try to use as much abstract and vague technical-sounding terms as possi…

I think that your response is overly accusatory, especially given that I think "grouping related data (and functions, if you're using OOP) together" is only one aspect of thinking in a type-oriented way, and not always necessary. A perhaps simpler, perhaps better example: Floats are lossy, but transactions in currency cannot be. An inexperienced developer might make the mistake of representing currency values as floa…

I'm sorry, for me it still more of a "how to define data" that "thinking in type". Full disclosure, i would create a struct like this: typedef struct Transactions { int value; char currency; } Transaction; (sorry for the naming and the poor c code, i've not done any c since 2016).

If the transaction value can be superior to 21 thousands (or if the code is deployed on a 32bit system, or if i want my floating point value high), maybe i would use a long, and probably an enum to keep track of the different currencies the second time i pass over the module. Maybe even a field (or a macro outside the struct) with the floating point value (4 to 6 seems good enough tbh).

I'm an "int, char, loop" guy, at least at first, especially if i have to write something from scratch. Thinking in "object" or "type" makes me uncomfortable except when it is for interfaces (but GUI makes me uncomfortable too, so...). I feel this is inefficient, and that well-defined/organized data should not need such complex handlers in most cases.

Re: Skills Poor Programmers Lack

#193

Post by JohnBooty » Mon, Jul 22, 2019, 8:35 AM UTC

AzzieElbab wrote: post #156

JohnBooty wrote: post #143

> Programmers who only work on small temporary > projects (like an agency) may get by without > ever improving how to design programs. Amen to this. We recently ended our engagement with a very well-known Ruby consulting shop for exactly this reason. Their engineers were very smart and wrote very pretty code. However it was not suitable for the real world once even a little bit of scaling was required, and this was a…

Weird, I find this to be more frequent the case for people who work on large, long lived, legacies

Which part? The inability to write code that scales, or the arrogance/ignorance about what they don't know?

The "arrogance/ignorance about what they don't know" part most definitely exists everywhere, including people who work on long-lived legacy apps. Definitely agree with you there, if that's what you mean.

Re: Skills Poor Programmers Lack

#194

Post by JohnBooty » Mon, Jul 22, 2019, 8:38 AM UTC

cosmodisk wrote: post #152

JohnBooty wrote: post #143

> Programmers who only work on small temporary > projects (like an agency) may get by without > ever improving how to design programs. Amen to this. We recently ended our engagement with a very well-known Ruby consulting shop for exactly this reason. Their engineers were very smart and wrote very pretty code. However it was not suitable for the real world once even a little bit of scaling was required, and this was a…

This is the problem I've got at my current job. While I try my best to write code in a way that it'd work many years ahead, the lack of scale requirements and relatively freedom I've got on my own decisions are double edge sword most of the time. Would love to work in a large shop with more senior people than am.

Both kinds of experience are so valuable. "Consulting shop" experience where you get to play with a lot of stuff, often very cutting edge stuff.

"Long lived legacy app" experience where you really get into the nuts and bolts of engineering some software, but you are often locked into a particular stack and the cutting edge is your enemy and not your friend. Can suck big time when you look for your next job and your skills are 5, 10, whatever years out of date...

Re: Skills Poor Programmers Lack

#195

Post by machiaweliczny » Mon, Jul 22, 2019, 8:42 AM UTC

29athrowaway wrote: post #104

Poor programmers are optimistic: * computers will always run my code fast * infrastructure problems will not happen * our team will always have plenty of time to understand my code * users are not malicious and the libraries I depend on are not malicious * I will always have to plenty of time to diagnose and fix problems in this code The author covers some of that. But you can care about those, and still be a poor pr…

You don't. (to both questions)

I don't know about you - but I can spot it by glancing through MR and just expect code provider to explain his solution in description or be "obvious" to me. So sulution to not having these problems is code review.

And if you have this problem then well, you have bigger problem (bad CR). But fixing it all at once is bad idea. Just fix modules you are working with/at.

EDIT: I spot it by checking imports/exports and API surface, so could be automated.

Re: Skills Poor Programmers Lack

#196

Post by [deleted] » Mon, Jul 22, 2019, 11:32 AM UTC

allannienhuis wrote: post #173

coldtea wrote: post #123

Earlier quoted context omitted.

Which is not really needed here. isDone will be boolean, and the other ones are still Truthy / Falsey values...

if the first term is undefined, isDone will be undefined, not false. At least in Javascript. && returns the falsy value on the left side of the expression if it evaluates to a falsy value (undefined && true) evaluates to undefined correspondingly || returns the truthy value (which might be an object) on the left hand side if evaluates truthy. That's useful for expressions like this: const a = b || 'default value'; !!…

[deleted]

Re: Skills Poor Programmers Lack

#197

Post by coldtea » Mon, Jul 22, 2019, 11:38 AM UTC

adamparsons wrote: post #188

coldtea wrote: post #115

Earlier quoted context omitted.

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

Actually you very specifically choose your posting environment as an individual, what an odd and misleading statement. It’s a shame that you write content but don’t believe it to be important to care about the largest fraction of readers. I’d hope for your sake that you reconsider.

>Actually you very specifically choose your posting environment as an individual

And most people just chose one that's easy to register/use/setup, and could not care less about details like design, typography, special formatting, load speed, and so on. They just want to put their words out, words being the important part.

The rest is more common for designers, fiddlers and pedants...

>what an odd and misleading statement

And also, how true and common...

Re: Skills Poor Programmers Lack

#198

Post by 29athrowaway » Mon, Jul 22, 2019, 2:10 PM UTC

machiaweliczny wrote: post #195

29athrowaway wrote: post #104

Poor programmers are optimistic: * computers will always run my code fast * infrastructure problems will not happen * our team will always have plenty of time to understand my code * users are not malicious and the libraries I depend on are not malicious * I will always have to plenty of time to diagnose and fix problems in this code The author covers some of that. But you can care about those, and still be a poor pr…

You don't. (to both questions) I don't know about you - but I can spot it by glancing through MR and just expect code provider to explain his solution in description or be "obvious" to me. So sulution to not having these problems is code review. And if you have this problem then well, you have bigger problem (bad CR). But fixing it all at once is bad idea. Just fix modules you are working with/at. EDIT: I spot it by…

You cannot do CR retroactively.

Re: Skills Poor Programmers Lack

#199

Post by rjpc » Mon, Jul 22, 2019, 2:18 PM UTC

FuckButtons wrote: post #185

rjpc wrote: post #138

Earlier quoted context omitted.

Yeah, context and empathy are two things that I'm only appreciating more and more as my career goes on. I once had this small but terribly written module written by an inexperienced developer who wasn't given the kind of feedback and code review that he should have been given. It was still running in production years after that person had left because it was in a corner of the code base that was basically never touch…

What was involved in their mentorship plan?

This was years ago, so my recollection is a bit fuzzy on the details. But pair programming was mentioned, and they also thought about what kinds of tasks to assign and how to provide scaffolding.

So for instance, instead of giving a really broad assignment and then going through six rounds of code review because everything is wrong, sit down with them in the beginning and make an outline (while explaining the rationale) of classes, methods, and responsibilities. Then have them fill in the implementations. That way you can use code reviews to focus on a lot of the smaller issues that are more concrete and less hand-wavy, while giving them practice working within sane high level designs. As time goes on, move on to more abstract concepts and give them more design latitude until they're capable of making a module like that by themselves.

There was a bit about walking the fine line in how much direction to give -- too little and they're lost at sea and spending forever to merge changes, too much and you stunt their growth.

I think there was also a book recommendation, but I have completely forgotten what it was.

Anyhow, they said it all a lot better than this, and I really wish they had accepted our offer. :-P

Re: Skills Poor Programmers Lack

#200

Post by cjfd » Mon, Jul 22, 2019, 2:41 PM UTC

techslave wrote: post #163

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…

> it actually takes somebody good at programming to perceive the difference between good and bad programming. sorry that’s not true. there are plenty of products (let’s limit ourselves to digital products) where consumers can differentiate between good and bad programming. they may not realize it’s the programming that’s the problem, but they can tell the difference. for products where the user can’t tell the differe…

The customer can and will perceive bugs. E.g., I used to own an MP3 player that would crash regularly. Everybody can notice that a crashing MP3 player is lacking in quality. What is more difficult is knowing who in the team contributed to a good or to a bad result and who of the programmers was a dead weight on the team. One really needs to know a lot about programming to say anything useful about that.

I agree that what the user can tell is the most important attribute of quality. There is is another important matter, though. This is how easy it is to modify the software. Good code can relatively easily be extended to incorporate new features and bad code makes this as difficult as possible.