Live data from Hacker News

The Number One Trait of a Great Developer

tammersaleh.com

101–110 of 122 posts

Re: The Number One Trait of a Great Developer

#101
post #86

Earlier quoted context omitted.

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

Having only used Oracle, MSSQL, and MySQL, I can't imagine a small 500-user app would be that hard to implement in in Postgre even if I'd never touched the platform before - does Postgre have some terrifying gotchas, or does it work as a reasonably well-behaved SQL server? That is, if I naively installed a PostgreSQL server on my box and started creating tables and indexes and users, would I be destroyed by some horr…

It's my understanding that there are no config gotchas in PostgreSQL (unlike MySQL). I've definitely found it more of a pain to set up at first. This is because the default role is very restricted and defaults to safe.

Re: The Number One Trait of a Great Developer

#102
This is a pretty bad article. Sure judgement is important, very important but sometimes using a new better set of technologies is the better judgement. That doesn't make things inherently un-maintainable just because it's new. That's where the judgement part comes in, knowing which new technologies to use in order to build a better/more maintainable system. This smacks too much of the author saying this is what I know so it's the best and everything else is crap.

Re: The Number One Trait of a Great Developer

#103
Listen to the why's, and not the what's, and you'll hear judgement.

In my experience this is very ill-advised. The answer to "why" questions varies so dramatically that it's extremely difficult to get an unbiased, realistic answer to those questions. I normally ask a bunch of "how" questions and eventually you unravel the "why".

The questions presented sound good on paper but don't matriculate that way in person. For example:

What's your least favorite part of Ruby and the Ruby on Rails framework, and why?

Tell me about the last time you used an interesting bit of technology, and what you learned from it.

Are much more naturally spoken as:

How do you feel about your least favorite parts of Rails?

How have you benefited from an interesting bit of tech?

It's amazing how much more human responses become when you use the words "how" and "feel".

Re: The Number One Trait of a Great Developer

#104
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.

The quality of an implementation is rarely tied to the tools except in extreme cases. A good Developer in general builds good solutions no matter the toolset. A good python developer is likely to become a good Objective-C developer if they invest the time to learn and because they understand the need for clean modular code the iOS code is likely to turn out pretty well.

Re: The Number One Trait of a Great Developer

#105
Hacker news commentary options on coding advice: 1. Spin the advice to make it sound like the advice is bad 2. Turn the advice around to make the author look bad 3. Criticize technology choices ( promoting your own choices of course ) 4. Some variant of "duh" or "don't reinvent the wheel" 5. Lament the sad realistic state of the programming world 6. Cast the author and others into various categories ( such as what I'm doing now )

Re: The Number One Trait of a Great Developer

#106
There seems to be a self-imagined divide between these two "camps" of developer. We see:

1. Hipsters that throw tools at a problem, and are eager to know as many different languages/frameworks/tools as possible, to stay ahead of the curve.

2. Developers that have picked a framework, and stick with it for life. They learn when necessary, but their framework can handle most problems thrown at it.

I would consider myself a part of both camps. I read Hacker News because people talk about these tools in use, and I love sitting down at home and toying around with new JavaScript frameworks, and different environments/tools. However, I have a job where I use a proven framework, a solid language, and a role where I model problems with a team of like-minded developers.

Now, imagine the scenario. I toy around with a new framework and absolutely love it for some use case. I decide to write a tool using Node.js, I use Bootstrap, and then I post it on my blog, Twitter, and on Hacker News. Some will check my work out and think it's cool, and others will look at it and will vomit at the very thought of JavaScript running on a server when another server-side language/framework would be far more suited to the problem at hand.

The point I'm trying to make is that developers are so keen to slate projects/code that was written for fun. My Node.js application isn't very good. Hell, I can probably write it a million times better in the language I actually use day-to-day in my job. I just wanted to release it so others can learn from it, and to show that I'm capable of keeping up with everyone else that is releasing apps-a-plenty in all these crazy new languages I see every day.

I agree with the general idea of the article, but only because developers are starting to embody these camps. I see entry-level/junior developers that apply for jobs with CV's that list every language they've touched for at least half an hour, and I see battle-hardened developers complaining about people trying to legitimise new tools because they're "not as good" as the tools that everyone else uses.

Re: The Number One Trait of a Great Developer

#107
post #62

Earlier quoted context omitted.

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

I got the same feeling as you niuzeta, and I feel the article may be getting judged a little too harshly (although I find the assertion of this being the best quality in a developer a little too absolute for my tastes). I think the author stated in the article that the fictional character Jack ".. makes a point of starting each project with at least three new technologies." I personally understand this as three new t…

>Finally I'd like to add that the author didn't say this was a "maintenance nightmare", he did however say the solution was elegant, scalable and totally unmaintainable.

Which is impossible, right? If it's elegant, it's maintainable. That's part of the definition of elegant software. A on liner that does amazing things, that very few people understand is not elegant. The same thought scales up to a whole solution IMO.

Re: The Number One Trait of a Great Developer

#108
I find the list of comments regarding this being "narrow minded", "contrived" or generally this being "a bad article".

It isn't, it's spot on. If you're outside the bizzaro world of overvalued, under-producing nitwits, the vast majority of technology is written on what's already understood by the team/developer. Because, you know they have budgets, and project managers, and families.

Jack isn't a rockstar, he's a self-important ass using his employer's/client's funds to learn a new technology that no one can maintain.

Re: The Number One Trait of a Great Developer

#109

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…

From a management perspective, it is easier to hire competent new employees for established, popular technologies.

Employees don't stay around for long anymore, especially dynamic, innovative employees who stay up to date on the newest technologies. People like that get recruited away all the time. Then who's going to maintain your bleeding-edge system? How long will it take to hire another employee of the same caliber?

If you're a top company who can afford to recruit and keep the best employees, then by all means, build on the latest and greatest. There is certainly nothing inherently wrong or unmaintainable about technologies just because they are new.

But if you're a medium or middling company with significant turnover in the tech ranks (i.e. most companies), then it's probably safer to build with the most popular, "standard" tech you can get away with.

Re: The Number One Trait of a Great Developer

#110
post #86

Earlier quoted context omitted.

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

Having only used Oracle, MSSQL, and MySQL, I can't imagine a small 500-user app would be that hard to implement in in Postgre even if I'd never touched the platform before - does Postgre have some terrifying gotchas, or does it work as a reasonably well-behaved SQL server? That is, if I naively installed a PostgreSQL server on my box and started creating tables and indexes and users, would I be destroyed by some horr…

They're similar, but there are some pitfalls you need to be aware of: count(*) optimisation in mysql for example. Different behaviour in the query optimiser. Most cases are easy to handle, but if you're used to mysql, there's still a learning curve.
Post reply on HN