Live data from Hacker News

The Number One Trait of a Great Developer

tammersaleh.com

61–70 of 122 posts

Re: The Number One Trait of a Great Developer

#61

Dianne's solution creates a maintenance problem if the number of devices grows too much or if network stability is a problem, or if there is an expectation down the line of, for instance, push sync. My point is not that her solution was not valuable, but that to suggest that the maintainability of the two solutions is black and white like this is wrongheaded. The really unfortunate implication here is that learning n…

Actually, why wouldn't a web service with a mysql server not scale for many orders of magnitude more users than they expect?

MySQL can easily scale to well beyond the "500 users" unless each of those users puts an especially heavy burden on the data store. The scenario at hand is synchronizing recipes and that is not a heavy burden.

Further, with a high-performance web framework, foregoing resilience (not recommended, but just for argument's sake) a single web-application instance should be able to handle a much larger number of users as well.

But all of this isn't really relevant to the point made by the OP. He's just using these fictional data points as an illustration. Although I am personally in favor of using examples that are more representative of reality, I think we can mostly ignore the fictional data points to appreciate his point.

Re: The Number One Trait of a Great Developer

#62

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.

> The result was a combination of Google Protocol Buffers, node.js, and Cassandra. Elegant, scalable, and totally unmaintainable.

If I can venture a guess, Jack went ahead (without asking further questions, as opposed to Dianne) and took what was very hot at that time.

2 years ago, Node.js was extremely hot, in a sense that it was the new thing that somehow combined the hot javascript and made something easier. I remember my collegate excitedly talking about the amazing serverside javascript.

I don't know about Google Protocol Buffers and Cassandra but I assume they were what the author had in mind as 'very-hot-but-not-widely-used-yet', and most technology that fits such description generally falls into 'not-reliably-stable' and 'not-many-resources-yet' category.

Think how you would do Java EE without help of Javadoc.

Re: The Number One Trait of a Great Developer

#63

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 that would give the users the ability to share their works, produced in an embedded environment, with their communities - a "Cloud" for the users. I designed the system architecture of the embedded system to be as self-maintainable as possible, and as simple as possible. Since its an embedded OS environment that the users would be using, instead of writing code I integrated such tools as git, and designed a system topology that would allow the user to be shielded from all the git hassle, while still getting a push-button experience.

I lost the gig to someone who decided that it would be better to re-invent "topography ordering" (his words) in a custom MySQL+PHP application, and when I was given an opportunity to challenge his design, I said "great, you're going to re-invent Git, poorly".

He spent the rest of the day "pissed that you compared his project to .. GitHub", which is what he thought I meant when I said "git". Nope, I said "git", I mean "git" - not 'github'. He actually didn't know how to use git.

Either way, off they go .. re-inventing the DAG with MySQL+PHP in an embedded environment, when they could've just wrapped the feature in a git script ... yikes++!

So this article just demonstrates to me that there are a lot of blow-hards out there who just don't get why its so important to apply the NIH principle to themselves, not just others ..

Re: The Number One Trait of a Great Developer

#64
post #12

No, that's the number one trait of a great employee - and the sign of a leader. The number one trait of a great developer is literally their ability to quickly write amazingly elegant code and manage complexity.

"quickly write amazingly elegant code and manage complexity"

No... the number one trait of a great developer is to reduce complexity in systems to a maintainable and cost efficient state.

Any developer that introduces complexity such as introducing tech stacks that no one else on the team comprehends is not "great" no matter how elegant their code. They are a liability to the employer.

Unless, of course, that developer is self employed and is developing a solution for themselves. But that isn't what the article was about.

Re: The Number One Trait of a Great Developer

#65
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…

Personally, as a dev, I push myself a little with each new project. I've been using Sinatra for all my web projects, with this latest one I took the jump to Rails. Otherwise the project fell squarely within my realm of knowledge, as a previous project showed me how the Facebook API works.

The time before that I tried to incorporate good OO style.

Next time I think I want to incorporate testing. Or maybe I won't feel that the next one is the right time to incorporate it, and instead I'll pick up a new Javascript library.

As devs, we have a remarkable ability to shape a project by choosing which technologies to use. So long as we exercise good judgment, we can learn new things on the job and not have to bet the farm.

As for MySQL / PostgreSQL, that decision probably didn't matter all that much for the given problem. Abstracted over with Sequel, they're pretty much interchangeable until you get to heavy, industrial-scale use. A lot of people can go an entire career without needing to figure out the use case for each.

Re: The Number One Trait of a Great Developer

#66

Earlier quoted context omitted.

I agree with the op but have a different spin on it. It depends on what you see as your core business. Is your business about the technologies used to build the application or are you using technology to let, "kitchen devices synchronize their list of recipes". If your business is the later then you are better of using tried and tested technologies your developers are familiar with and can maintain without detracting…

I think the exact opposite holds true. If you're a MySQL / Sinatra shop, being the best at MySQL is the goal - double this if you're working for clients. If your job is to provide the best possible kitchen device sync platform, then doing on the job research into improving that is essential to the business.

I do not disagree with you. It is all relative and the most important thing is to know what your core business is. Using a car analogy, car salesmen and engineers both need to have technical knowledge of the cars they work with. One focuses on selling cars and the other making the cars. I think too often start-ups are not too clear on their core business. Engineers know the cars better than the salesmen but does that make engineers better equipped to sell cars?

Re: The Number One Trait of a Great Developer

#67

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.

Because apparently the author didn't have the necessary skills to maintain it. Cassandra isn't easy to master, especially if you only have cheapo developers who are reluctant to switch to PostgreSQL from MySQL.

But yes, it's a highly opinionated, narrow-minded piece.

Re: The Number One Trait of a Great Developer

#68
post #37
post #15

This is a problem because writing working, maintainable code that solves the given problem rather than an imagined problem should be the trait of a competent developer. I had the pleasure of going on a course run by a German developer recently, and his brutal focus on quality and maintainability made me rethink what we class as a good developer. Brutally in the article Jack is not a rockstar - Jack is incompetent. A…

Maybe we should be asking why the things we make need to be maintainable. Why can't I just make program module x to input a and output b and never touch it again. I believe modular code is the future and the sooner we get there the better.

What do you do when bugs show up in that module? rewrite it from scratch, introducing god knows how many new bugs? Or only address bugs when a rewrite of the entire module is necessary?

Re: The Number One Trait of a Great Developer

#70
Learn new technologies on your own time. Don't use the client to fund you picking up the latest-greatest whatever. That's what personal projects are for. You take the knowledge gained from your personal projects (and unforeseen circumstances in paid projects that you had to code your way out of) and do what you know will work the requirements, versus what will be exciting for you.
Post reply on HN