61–70 of 86 posts
Yeah, hire below-average developers instead and never end the job of cleaning up. I heard about startup that changed team three times, and had to rewrite codebase likewise.
Unless you think the average is "superstar".
Earlier quoted context omitted.
yeah. I've seen a lot of comments like: // Sleep for 10 minutes sleep(15*60) Unfortunately, the compiler cannot check your comments. Don't put facts that are better looked up in the actual code and that they only risk getting out of sync with the code.
That's a useless comment. A better one would be: // Prevent the two tasks from running right after each other, // to reduce load when this is run frequently sleep(15*60) Even the most junior dev can infer that a multiplication by 60 for a sleep function probably means the unit is seconds and we want 15 minutes. No need to spell that out. But why sleep for 15 minutes and not just carry on to the next task? THAT is wha…
Earlier quoted context omitted.
yeah. I've seen a lot of comments like: // Sleep for 10 minutes sleep(15*60) Unfortunately, the compiler cannot check your comments. Don't put facts that are better looked up in the actual code and that they only risk getting out of sync with the code.
And to keep with the theme of self-documenting, the self-documenting version of that would be: NAP_LENGTH_MINUTES = 15; ... sleep(NAP_LENGTH_MINUTES*60);
Earlier quoted context omitted.
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…
>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 That simply means you're working with poor developers.
I would add a second element to the title "You Don't need Superstar Developers: You Need High-Acheivers" The challenge is really having a mixed team of high talent and minimal talent. While yes, those who are of lower talent will learn more from the super talented, the inverse is not always true. I have found many lazy (or at least not super motivated) devs who have the required minimum competence level, but are not…
1. Smart.
2. Gets things done.Earlier quoted context omitted.
And to keep with the theme of self-documenting, the self-documenting version of that would be: NAP_LENGTH_MINUTES = 15; ... sleep(NAP_LENGTH_MINUTES*60);
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.
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 documents itself.
Earlier quoted context omitted.
> 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…
>A LOT of companies think what they're doing meets that definition when it really doesn't. Can you back that up with data? The majority of companies in the US have zero problems hiring developers who aren't rockstars even when their business model is unique for their industry. My evidence is the disproportionate number of questions from developers on Stackoverflow asking things that they would know if they had a dece…
Earlier quoted context omitted.
>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. Even the average CRUD plus workflow application is only really routine & repetitive if you're using suboptimal tools. If you're good, you're good at choosing the optimal tools and automating all the tedious stuff. In large companies, managers would rather have a mediocre…
"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…
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 toxic personality.
I've known many developers who rarely talked, rarely spoke up during meetings and just quietly got on with their job - building code to spec - and did it really well. They were, sadly, always highly underrated as developers and judging by what I've read in this thread, this is a prejudice that isn't likely to disappear any time soon.
Earlier quoted context omitted.
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…
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…
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 problems extend to not being able to state numbers then you do not have a lack of soft skills, you have crippling brain damage.
>He may be unable to explain why more time for refactoring
Developers usually don't have to explain to other developers why more time is needed for refactoring, showing them the code in need of a refactor is usually enough.
PMs may ask why but they don't need to why and they probably don't care why anyway.
>It is not possible to write specs completely without ambiguity - just like no one writes code without bugs.
And? Going over to the PM and asking them to clarify a few details isn't exactly the hardest part of a developer's job. Average levels of communication skills suffice. It only becomes challenging when the PM writes horrendously ambiguous specs.
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.