Live data from Hacker News

You Don’t Need Superstar Developers

blog.lunarlogic.io

71–80 of 86 posts

Re: You Don’t Need Superstar Developers

#71
post #7

Earlier quoted context omitted.

Besides, code speaks to the compiler/runtime; comments speak to the human. - The machine need to know HOW something should happen. That's code. - The human needs to understand WHY that thing should happen that way. These are two different objectives, and good quality code weaves the two in the appropriate measure. Having said that, I don't believe all code should be reduced to the subset that a junior dev can underst…

Wrong. Machine code is for the computer. Human readable high-level languages were designed specifically for people.

Different newspapers write to different education levels. In your local paper you may find writing that a grade 8 student could understand. In your industry specific journal the writing may be at a grade 12 level.

Not all code should or can be human readable by all.

Re: You Don’t Need Superstar Developers

#72
post #63

Earlier quoted context omitted.

Still not good enough. Why is this nap function in there? If I want to make it faster and didn't know, I would just remove all references to it. What did I break? Can't tell by that variable name.

a) Self documenting doesn't mean no comments b) I didn't give enough context for your specific commentary to really make sense. I mean, when did I even say this is a function? It's a snippet of pseudo-code not a code sample. c) Are you really running around programs ripping out references because you don't know what they do? I'd advise working on your definition of optimization before worrying about whether your code…

>Self documenting doesn't mean no comments

Agree. I assumed you were giving an example of self documenting code that doesn't require comments.

>I didn't give enough context for your specific commentary to really make sense. I mean, when did I even say this is a function? It's a snippet of pseudo-code not a code sample.

Yes, sorry. I've just spend the last month digging into shitty code, so I'm in dealing with shitty code mode. My point was the name you gave it didn't give any intent as to why the application would be napping, which is probably the most important information. Of course, as you said, the owner function could be named properly in that way.

>Are you really running around programs ripping out references because you don't know what they do? I'd advise working on your definition of optimization before worrying about whether your code documents itself.

It's pretty common for developers to try to figure out why an application is running slow. If I saw that (sleep function), it would be an obvious sign of why it's slow. If I saw that I would immediately see it as a potential target of improvement. Unfortunately with just the label you provided and a poorly named owning function, I wouldn't have enough information to determine if it was removable because, again, I don't know why it is napping. I would then have to spend several minutes/hours/days ($$$) determine what the hell that nap was for. This could all be solved by a comment providing intent.

I would suggest instead of NAP_LENGTH_MINUTES, it would be NAP_TO_AVOID_PROCESS_COLLISION_LENGTH_MINUTES or something. Of course, naming things properly is one of the hardest things in computer science. :)

There are only two hard things in Computer Science: cache invalidation and naming things.

-- Phil Karlton

Re: You Don’t Need Superstar Developers

#73
post #3
post #2

One of my most useful insights in software development is that no matter how smart you are, if you write code that can't be understood by a junior developer, it means that you didn't do a good job writing that code.

And the reason that "the code is self-documenting" is a bad smell is because in 3 months even the 'rock star' who wrote it won't remember without appropriate help (eg comments). I've worked with some pretty smart developers in some pretty interesting roles, and the people cock-sure of themselves are rarely anything other than a poisonous danger to overall performance and deliverables typically. I say this as a lone w…

A self-documenting code means we can (relatively) easily see what is being done by the program just by reading the program.

What is one question; why is another. When we work with the existing code (debugging, maintenance) we need to know answers to both questions. So, in addition to a well written (self-documenting) code base we need a document explaining the rationale for the choices that were made and, more generally, the context in which the code was created.

Re: You Don’t Need Superstar Developers

#74
post #54

Earlier quoted context omitted.

A developer may also fail in communicating how much time will something take, explaining clearly to pm why is feature harder to implement or not feasible due to existing architecture. A developer may fail at asking questions clearly - so the pm don't even know what info is missing. He may be unable to explain why more time for refactoring is needed or why change of technology is needed. It is not possible to write sp…

>A developer may also fail in communicating how much time will something take Estimation is not a communication skill. >explaining clearly to pm why is feature harder to implement A PM is probably not interested and does not need to know why they just need to know that it is hard to implement. I've typically done that by assigning a number (1, 3, 5, etc.) to a story indicating its difficulty. If your communication pr…

People with bad communication skills often think they are communicating big estimate, while no one else in the room got it from what they said. It happens. Or they refuse to hear when someone suggests easier solution or change of requirements so that it can be done faster.

Nope, showing the code is not enough to explain to other developers, unless we are talking about something extremely clear, simple and small. And yep, developers tend to have different opinions about what is important. The expectation that they will automatically share your concerns is pretty much how developers with lower social skills fail - and why lack of it slows everyone down. (And then they complain about everyone being stupid while the issue is they did not expressed themselves clearly and did not listened to contraarguments).

And PM IS interested, good one that is. It helps him to argue to customers/his bosses/other departments. It helps him to trust you. It helps him to distinguish between something that can wait and something that need to be done soon (you had him doing all prioritization and you claimed developer does not need such skill). Software estimates are wrong often enough that good PM won't take them as granted. At minimum she needs a sense of risks. It helps him to change the spec so that new one is doable faster.

Have you even consider entry that PM can react to reasons why something take long by changing spec, changing priorities, negotiating more or finding someone more experienced I that are to help you? Good pm do all the above. Which is why they can achieve more if people under them cooperate.

On your last point - given that developers with bad communication skills ask badly phrased questions or don't ask anything at all (just generically complain about bad analysis and insult pm - true story), yep it matters.

You jumped from "bad social skills" to "average" there. The two are not nearly the same thing.

Re: You Don’t Need Superstar Developers

#75
post #50

Earlier quoted context omitted.

> If you're doing _groundbreaking_ research I think research is the key word here. If you are developing fundamentally new ML techniques (like the folks at Google), you'll probably need some serious technical chops. > Usually it is a rinse-test-repeat kind of job. It needs people with patience and who can interpret data and who can be comfortable with uncertainty and then can make their bosses comfortable with uncert…

> If you are developing fundamentally new ML techniques (like the folks at Google) Nope, still no superstars needed. The most technically challenging thing they've built is probably is what they are doing with the TPUs, but even there you "just" need people expierienced in the right fields. Most groundbraking research stuff these days is mostly on the mathematical side, not the implementation.

[deleted]

Re: You Don’t Need Superstar Developers

#76
post #29

It depends so much on what you're building. If you're doing _groundbreaking_ research in, say, AI or facial recognition or whatever, you may need people who are technical superstars. If you're building the average CRUD-plus-workflow application, the last thing you want are superstars who are going to get bored with routine work. Then they'll go off over-engineering some minor feature or spending weeks at a time inven…

> It depends so much on what you're building. If you're doing _groundbreaking_ research in, say, AI or facial recognition or whatever, you may need people who are technical superstars. I think this is true for high risk, cutting edge tech, the problem is that A LOT of companies think what they're doing meets that definition when it really doesn't. They think their NoSQL datastore with 10 million records and a single…

They think their NoSQL datastore with 10 million records and a single page frontend is the like putting someone on the moon.

And that they need to interview you, accordingly.

Re: You Don’t Need Superstar Developers

#77
post #60

Earlier quoted context omitted.

"Soft skills are vital for team lead and product management but being able to write a good email and butter up your superiors isn't too important for other developers." Unless you're a developer that works by themself on code that will never be used directly by other people, soft skills are always vital. Soft skills include things like being able to empathize with others, which is quite important for building usable…

>Soft skills include things like being able to empathize with others, which is quite important for building usable interfaces And, as with leaving product management to the professional product managers, it is usually better to leave the designing of UIs to the professional designers. >And, soft skills are incredibly important for getting along with others Not having good soft skills is not the same thing as having a…

They're not underrated; they're rated where they belong.

Re: You Don’t Need Superstar Developers

#78
post #2

One of my most useful insights in software development is that no matter how smart you are, if you write code that can't be understood by a junior developer, it means that you didn't do a good job writing that code.

>if you write code that can't be understood by a junior developer

Only true for simple apps (i.e., CRUD, etc.)

Re: You Don’t Need Superstar Developers

#79
post #48

Earlier quoted context omitted.

You're describing an idealized theoretical team organization model with strict separation between the engineering manager, product manager, and developer roles. In the real world with highly productive teams those roles tend to blur together. In order to produce actual business value — not just churn out code to spec — developers absolutely need to be able to communicate clearly, empathize with customers, and collabo…

It's a sad state of affairs if you consider it "idealized" to be able to focus on your job and rely on others to do theirs. Yes, in the real world you sometimes have to work with poor product managers who have little empathy with customers, who deliver unclear specs and vague priorities. That doesn't mean a good developer is somebody who can handle the parts of their job that they failed at. "Communicating clearly" i…

It's a sad state of affairs if you consider it "idealized" to be able to focus on your job and rely on others to do theirs.

It's a Platonic ideal of specialization, and in no way an ideal environment for actual humans. IRL, I wouldn't want to always be told precisely which task I should be on at every moment.

Re: You Don’t Need Superstar Developers

#80
post #60

Earlier quoted context omitted.

"Soft skills are vital for team lead and product management but being able to write a good email and butter up your superiors isn't too important for other developers." Unless you're a developer that works by themself on code that will never be used directly by other people, soft skills are always vital. Soft skills include things like being able to empathize with others, which is quite important for building usable…

>Soft skills include things like being able to empathize with others, which is quite important for building usable interfaces And, as with leaving product management to the professional product managers, it is usually better to leave the designing of UIs to the professional designers. >And, soft skills are incredibly important for getting along with others Not having good soft skills is not the same thing as having a…

And, as with leaving product management to the professional product managers, it is usually better to leave the designing of UIs to the professional designers.

If your company has those, sure.

Post reply on HN