Live data from Hacker News

The Number One Trait of a Great Developer

tammersaleh.com

71–80 of 122 posts

Re: The Number One Trait of a Great Developer

#71

This is one of those "why I am a great developer" sorts of posts that allows people to pat themselves on the back and congratulate each other on how great they are, passive-aggressively sending it out to the team in hopes of denigrating some team member who likes newer things. In this case "judgement" means "uses the things that I know", and there seems to be little evaluation beyond that high-level use case. Why was…

Yeah, I agree with you: 'just because' .. the author of the article doesn't know anything about protocol buffers, node.js and Cassandra. Probably because those things are 'too new' and 'not proven' technologies - to him. But if I had to take over a project from someone, to maintain it, I'd MUCH RATHER have it be done using those technologies than MySQL and Sinatra. Yikes! I recently had to make a bid on a project tha…

But if I had to take over a project from someone, to maintain it, I'd MUCH RATHER have it be done using those technologies than MySQL and Sinatra. Yikes!

Except that isn't really an option in most cases.

The two most realistic choices are: Take over a high-quality implementation using somewhat stale tools or an average to shoddy implementation with newer tools that the developer was learning on the fly.

Re: The Number One Trait of a Great Developer

#72
Jack drops a couple turds into your codebase, but so does Diane. Hers just take longer to arrive. Inability to seek actual best tools based upon personal fear of the unknown does not a great developer make.

Basing one's code off the familar or the purported "best practice" without actual knowledge leads to drek down the road. A great developer chooses the right tools for the task (along with other things...) Diane's, for instance has these flaws:

- Requires a relatively heavy runtime.

- Requires HTTP stack.

- Wastes CPU/power

These are not negligible considerations for embedded devices.

Someone who knew what the crap they were doing would likely have chosen a binary protocol standard (many such exist), then pumped that information out over an appropriate topology - someone suggested UDP. The database should probably be SQLite; maybe berkDB, depending on the complexity of the data model and the CPU used. Bluntly, the proposed "great" solution isn't. It's an inelegant solution putting heavy demands on the hardware unnecessarily.

Judgement is fine. What you use as a proxy in hiring for judgement is experience. E.g., you don't hire a Ruby dev to do embedded work. Experience tells you that.

What makes a developer great is great wisdom: knowledge applied skilfully.

n.b.: I wouldn't hire either Jack or Diane based on this article; Diane is fearful and Jack picked a javascript engine too immature for embedded. Jack might be led to understanding and might be worth more; I don't want to go around trying to convince people that better is better - I have no hope for Diane if she can't spend a day learning postgres.

Re: The Number One Trait of a Great Developer

#73
post #72

Jack drops a couple turds into your codebase, but so does Diane. Hers just take longer to arrive. Inability to seek actual best tools based upon personal fear of the unknown does not a great developer make. Basing one's code off the familar or the purported "best practice" without actual knowledge leads to drek down the road. A great developer chooses the right tools for the task (along with other things...) Diane's,…

I thought that in this contrived example, Jack and Diane were writing the software that runs on the server, not on the kitchen devices. Also, what if the "devices" are small-form-factor PCs? That would relax the constraints considerably.

Re: The Number One Trait of a Great Developer

#74
post #33

The catch-22, of course, is that at some point, MySQL was the "new thing" to Diane, so how did she learn it in the first place? The answer of course is that judgement is less about making decisions upon familiarity per se and more about knowing when unfamiliar technology seems to provide good trade offs given what is known about it. For example, PostgreSQL may be unfamiliar, but choosing it is a wildly different type…

I see this as a 3D optimisation problem. 1st dimension: power of the tool 2nd dimension: ecosystem of the tool (developers/libraries/support/etc) 3rd dimension: developer's ability to use the tool (time to learn, current ability, etc) If you think on factors going from 0 to 10, MySql could be [4, 7, 8] and Postgres could be [7, 7, 4] for that developer. Of course the 3rd factor depends on the developer (and on the ti…

I think another important dimension is the suitability of the tool to the technical culture and composition of the organization. For example statically typed java-ish languages tend to be more attractive if you have many disconnected groups contributing to a code base, and if I'm being cynical, overall less average skilled programmers just hacking out features. Whereas a small team of top-tier developers are more well positioned to leverage the benefits of more fancy tools and languages.

Re: The Number One Trait of a Great Developer

#76
post #71

Earlier quoted context omitted.

Yeah, I agree with you: 'just because' .. the author of the article doesn't know anything about protocol buffers, node.js and Cassandra. Probably because those things are 'too new' and 'not proven' technologies - to him. But if I had to take over a project from someone, to maintain it, I'd MUCH RATHER have it be done using those technologies than MySQL and Sinatra. Yikes! I recently had to make a bid on a project tha…

But if I had to take over a project from someone, to maintain it, I'd MUCH RATHER have it be done using those technologies than MySQL and Sinatra. Yikes! Except that isn't really an option in most cases. The two most realistic choices are: Take over a high-quality implementation using somewhat stale tools or an average to shoddy implementation with newer tools that the developer was learning on the fly.

.. or, take over a project that was done by a competent developer who knew what they were doing and were able to communicate that knowledge through their codebase to anyone else who might pick up the project later on - which is the real #1 Trait of a great developer, whatever technologies they're using ..

Re: The Number One Trait of a Great Developer

#77

This is one of those "why I am a great developer" sorts of posts that allows people to pat themselves on the back and congratulate each other on how great they are, passive-aggressively sending it out to the team in hopes of denigrating some team member who likes newer things. In this case "judgement" means "uses the things that I know", and there seems to be little evaluation beyond that high-level use case. Why was…

> Why was -- in this contrived scenario -- Jack's solution a "maintenance nightmare"? Just because.

Maybe this article will shed some light:

http://www.xaprb.com/blog/2010/05/10/the-manager-programmer-...

Re: The Number One Trait of a Great Developer

#78
post #72

Jack drops a couple turds into your codebase, but so does Diane. Hers just take longer to arrive. Inability to seek actual best tools based upon personal fear of the unknown does not a great developer make. Basing one's code off the familar or the purported "best practice" without actual knowledge leads to drek down the road. A great developer chooses the right tools for the task (along with other things...) Diane's,…

I thought that in this contrived example, Jack and Diane were writing the software that runs on the server, not on the kitchen devices. Also, what if the "devices" are small-form-factor PCs? That would relax the constraints considerably.

Ah, see, I read the spec as saying that it would be things stored on the kitchen devices (toaster, etc).

You do want to make sure your comms layer is easy to make reliable when talking from the device, regardless. Might be HTTP, might not be - I'd likely take a gander at ProtoBuf myself for feeding over TCP/IP to minimize comms complexity on the phone home code.

Re: The Number One Trait of a Great Developer

#79
post #71

Earlier quoted context omitted.

Yeah, I agree with you: 'just because' .. the author of the article doesn't know anything about protocol buffers, node.js and Cassandra. Probably because those things are 'too new' and 'not proven' technologies - to him. But if I had to take over a project from someone, to maintain it, I'd MUCH RATHER have it be done using those technologies than MySQL and Sinatra. Yikes! I recently had to make a bid on a project tha…

But if I had to take over a project from someone, to maintain it, I'd MUCH RATHER have it be done using those technologies than MySQL and Sinatra. Yikes! Except that isn't really an option in most cases. The two most realistic choices are: Take over a high-quality implementation using somewhat stale tools or an average to shoddy implementation with newer tools that the developer was learning on the fly.

Take over a high-quality implementation using somewhat stale tools or an average to shoddy implementation with newer tools that the developer was learning on the fly

My experience has been that developers who are most interested in innovations in this industry are dramatically more likely to build better solutions -- the passion and interest cuts both ways. Versus the career developer who does the absolute minimum necessary.

But of course with any given situation and set of developers your mileage will vary (I've known on-the-edge developers who build ridiculously nice code, and hanging-two-generation-back coders who make disgusting code. And vice versa). This particular scenario bothered me because the nodejs / cassandra canards were propped up under the illusion that the only advantage they offer was nefarious "Web Scale". Only in reality for many projects they make it ridiculously efficient to build solutions. The same goes for Go right now -- there are practitioners who can build in moments what would have taken months on a, for instance, ASP.NET team.

Re: The Number One Trait of a Great Developer

#80
The problem they forget to mention is that Diane's skills stagnate. Sure she did better this time, but Jack has learned more. Next time through his solution will be faster and have less errors.

If everyone was like Diane and just chose what they knew we'd still be coding in Assembly and be nowhere near the throughput and capability we have now.

I often will try multiple implementations if I have the time, break the problem down to something simple I can do with a few languages and tools in a day, contrast them when I'm done and then go full scale with the one that seems a good fit. More times than not it ends up being a combination of all the solutions I tried because it gives me a chance to discover the strong points in each.

Post reply on HN