Live data from Hacker News

The Number One Trait of a Great Developer

tammersaleh.com

91–100 of 122 posts

Re: The Number One Trait of a Great Developer

#91
post #54
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…

>...so how did she learn it in the first place? I think that asking why a programmer knows any piece of knowledge is a very good glimpse into how competent she is. I don't care that somebody likes Git more than SVN but I do care why (on a technical level) somebody likes Git more than SVN.

For almost any piece of technology that I know the answer is one of those:

"I was forced to use it on that project" or "brief research showed it was the optimal thing to use on that project" or "I got stuck in project Euler"

Re: The Number One Trait of a Great Developer

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

Because x(a) -> b might need to be understood by everyone working with your module at some point. What if you leave the company and someone inherits your module? What if they decide to change their codebase and need to rewrite your module?

Writing modular code doesn't magically give you maintainable code either. It needs documentation, proper use of design patterns, and needs to be readable.

Re: The Number One Trait of a Great Developer

#94
I agree with the author. A few (actually still good) devs I know prefer to solve a problem in a sophisticated manner, scalable and all the stuff in 160 locs instead of using the non-scalable solution of 40 locs that will also solve the problem, if only for the next 12 months or so.

I think the problem is the incentives. As a founder I need the stuff done until some deadline while as an employee I prefer learning new stuff in a company.

So I found myself on both sides of this story and I have never been more productive than as a founder because I only choose the small scale solution because I can complete two tasks per day instead of one task every two days.

Note that 40 locs is meant as a placeholder for "quick to program and easy to maintain" code and 160 locs for "fast to execute, scales, worse to maintain"

EDIT: Worse to maintain as in "the solution is not immediately obvious or I need to understand the abstract concepts employed or I need to know some special lib to understand it". All three forms of "worse to maintain" are examples of a greater investment of time and brain to understand what's going on.

Re: The Number One Trait of a Great Developer

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

> In fact, to me the rings of the "worse is better" philosophy

Which is typically pushed by worse developers. How coincidental!

Re: The Number One Trait of a Great Developer

#96
On this subject. What I find funny, slightly scary and hugely rewarding is visiting old code and removing massive parts of it only to leave it doing pretty much the same thing.

It touches on a coding horror article about wanting to write code. Don't 'want' to write it, want to write as little as possible of it. If you do have to write it, write as little as possible and with the notion you'll be looking at it in 6 months going wtf.

Re: The Number One Trait of a Great Developer

#97
post #86

Earlier quoted context omitted.

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…

As someone who moved from MySQL to Postgres, the only thing that took some getting used to was users being actual Unix users that you create and then grant access to. At the time it seemed odd considering what MySQL did but it ended up being a feature I like quite a bit.

PG roles are stored in the DB, not Unix. You can set up pg_hba to use ident authentication so that users are automatically granted access by their Unix login, but it isn't the default (and usually not recommended), and you still have to have PG roles in the database for them to correspond to. So I think there's been a misunderstanding.

Re: The Number One Trait of a Great Developer

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

Coming from a functional programming perspective on code quality, I think new code written with a modern understanding of software engineering generally is better quality than old code backed by tech written with last decade's understanding.

Re: The Number One Trait of a Great Developer

#99
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 know MySQL because a decade ago I was a very bored high school student and was interested in making websites. And it's free.

Re: The Number One Trait of a Great Developer

#100
post #78

Earlier quoted context omitted.

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.

I think I'd use HTTP as the synchronization protocol, because GET and PUT are specified as being idempotent, meaning it's safe to retry them. Also, HTTP is a ubiquitous standard, meaning there are several implementations to choose from, on both the client and server sides.

The ubiquitous of HTTP is indeed a definite point in its favor(as is its popularity and level of documentation).

> GET and PUT are specified as being idempotent, meaning it's safe to retry them.

Entirely OT: Abstractly, yes, that's how they should be implemented, but they don't have to be and consequently it's entirely up to the receiving server whether they are or not. Which, in terms of assuming that someone will make unverified and bad assumptions, means that the implementer at some point will let them slip and become non-idempotent.

Post reply on HN