TR Forums

notfred wrote:

I was branded a trouble maker for complaining about the extra complexity of his code which improved things from 15.1s to 15.01s.

At least the guy didn't take your source code, apply that 0.01% performance improvement to it, and then call it "his" because of his "substantial time" spent improving on it.

I've had that happen enough in the open source community, which is why I don't program any more. It feels like a cesspool of leaches.

Much has been said but I will add up to this too.

Being a good programmer means being a different type of human mind. Let me explain. To write code very well you gotta think like a poetic machine. Note - not as a machine, but as a portic machine. There is a place for creativity in writing code for sure, it's just that its a different type of creativy - not the one you use when writing a song and painting. This creativity is sctructures and placed in order while it still does not lose it's power.

Thinking like a machine does won't make you a good programmer. But thinking like a creative machine will deff-ly do it.
Hope I made it clear.

notfred wrote:

I found several bugs in his code (which admittedly he did address) whilst looking at why some of the queries took 15 minutes, put some proper indices in and had them running in sub 15-seconds. I was branded a trouble maker for complaining about the extra complexity of his code which improved things from 15.1s to 15.01s.

Yup, learned the hard way that one must give some thought to politics too. The most important thing though is to stick up for yourself, even if everyone else is against you.

Vorobei wrote:

Being a good programmer means being a different type of human mind. Let me explain. To write code very well you gotta think like a poetic machine. Note - not as a machine, but as a portic machine. There is a place for creativity in writing code for sure, it's just that its a different type of creativy - not the one you use when writing a song and painting. This creativity is sctructures and placed in order while it still does not lose it's power.

Would you say it's the kind of creativity that one exercises when putting Lego blocks together, or when making your own Lego blocks? That seems like an apt metaphor to me.

notfred wrote:

I found several bugs in his code (which admittedly he did address) whilst looking at why some of the queries took 15 minutes, put some proper indices in and had them running in sub 15-seconds. I was branded a trouble maker for complaining about the extra complexity of his code which improved things from 15.1s to 15.01s.

Too true. All too true.

I remember my first job, straight out of university: we were writing a billing system (don't ask, or I'll have to go find some brain bleach.) Amongst other things, this system had to interface with other systems - passing details about financial transactions and the like, using delimited text files (sometimes fixed width, sometimes CSV, sometimes a brain dead abomination from the pits of hell.) I worked on a fair chunk of these interfaces; in fact, I wrote the first or second one that was implemented.

My colleagues copied and pasted the code into their work when they had to do their own interfaces. (Experienced programmers at this point will be laughing hysterically, if they aren't sobbing into their drinks.)

Cut to several months later. We discovered a bug in one of my interfaces, which I duly fixed. A week or two later, I was assigned another bug report. "Hmm - this looks familiar." Sure enough. So I went to management, and told them the situation; I wanted to move the duplicate code into the superclass, and use inheritance to override whatever behaviour varied between interfaces (which, for the functions in question, was very little), because I believed that there was a near certainty that the bug would appear in all the other interfaces, and it would be easier in the long run to do that, even allowing for the fact that it would require running tests on all the interfaces rather than just the one affected. They knocked me back. "We don't have time, just fix the bug you've been assigned."

No prizes for guessing what happened next.

So when somebody asks me what makes a good programmer, my response is simple: knows when, and how, to reuse code (making it generic if necessary), rather than copying and special-casing it in dozens of different spots. Not the whole story, it's true, but it's definitely a big part of it.

For the record, it was that job that burnt me out on programming and had me head into the realm of systems administration, which brings its own unique headaches, but that's a tale for another time.

danny e. wrote:

Uses readable code. Commented. team code style compliant. Good variable names - don't be schmuck and use short/dumb abbreviations. It's 2013.

^THIS!

You may be a UI expert. You may be a DB expert that is able to massage the mundane. You may be able to punch out complex code in minutes. You may be able to read code and can articulate the function/s. But if you don't comment and/or document it doesn't mean $#!7!

I can't tell you how many times I have inherited something at work that was done by someone else (Who is no longer with the company or was a contractor) it's broken and when I open it up it just line after line after line of useless code. Sure I can decipher the jumbled mess. But I should have to waste hours cleaning it up!

A good programmer/developer should take pride in their work and that means commenting everything! Even basic functions everyone (is supposed to) knows. It takes very little time to do and makes debugging even that much easier.

"Good programmers copy and paste good code. Great programmers copy and paste great code."

This was a quote from a Microsoft employee at a SQL 2008 launch event.

A good programmer makes efficient code, simple, fast, easy to read and maintain, and WELL DOCUMENTED.

A good programmer doesn't use variable and functions names like "dmuhfvbwiuhb", but "thisThingDoesX".

A good programmer understand that even himself will forget how his own written code works some months in the future.

A good programmer assumes that even the most carefully written code will not work as intended, and takes measures to deal with that.

A good programmer doesn't reinvent the wheel, because somebody already solved the same problem, and fixed all the bugs, and everybody knows how it works and what it does. Example, everybody knows what a dictionary does. Do not program a mysterious solution just to implement a dictionary. Use libraries.

A good programmer uses a profiler to check his code efficiency.

marraco wrote:

A good programmer uses a profiler to check his code efficiency.

You'd be amazed how many programmers have never, ever, touched a profiler.

Waco wrote:

marraco wrote:

A good programmer uses a profiler to check his code efficiency.

You'd be amazed how many programmers have never, ever, touched a profiler.

For many types of (non-performance-critical) applications, they aren't really necessary. So no, I don't find it amazing.

That said, I haven't just *used* profilers, I've *written* one.

just brew it! wrote:

For many types of (non-performance-critical) applications, they aren't really necessary. So no, I don't find it amazing.

That said, I haven't just *used* profilers, I've *written* one.

I guess that's true. I do HPC stuff, so performance matters a lot.

Also, which one? Open sourced anywhere?

I think there's really a difference between business and raw skill. I'm thinking of the moddemo scene (Amiga, C64, PC) where people were pulling off tricks like no one had ever seen on the hardware of the time. Even Carmack's earlier stuff like Wolf3D and Keen, before he got his NeXT and stopped doing so much ASM tuning.

You can't say that those programmers sucked because they didn't write properly documented code. But for business or working in a team setting, yeah, totally different rules apply.

Commenting is an art form. The Practice of Programming by Pike and Kerningham really goes into this properly. There is definitely such a thing as too much comenting and there's definitely such a thing as to little. Properly written code generally only contains minimal comments because the code is readable. It's when you do clever things or special edge cases that you really need a BOOK written. And those comments depending on internal processes might not even be written IN the code, but instead in the project notes/bug archive.

Waco wrote:

just brew it! wrote:

For many types of (non-performance-critical) applications, they aren't really necessary. So no, I don't find it amazing.

That said, I haven't just *used* profilers, I've *written* one.

I guess that's true. I do HPC stuff, so performance matters a lot.

Also, which one? Open sourced anywhere?

It was for a custom massively parallel system at Fermilab, many years ago. No longer in use.

just brew it! wrote:

It was for a custom massively parallel system at Fermilab, many years ago. No longer in use.

Respect++

marraco wrote:

A good programmer understand that even himself will forget how his own written code works some months in the future.

My experience has been that you can potentially forget how your code works if you just get up to get more coffee.

IMHO, a good programmer these days is a master of different relevant programming languages, shoots for code efficiency and minimal bloat, and just can't have enough cores to program for!

ronch wrote:

...and just can't have enough cores to program for!

Always the goal.

Waco wrote:

ronch wrote:

...and just can't have enough cores to program for!

Always the goal.

Closer to the truth than you might think. Since we're apparently hitting a wall on GHz and single-core IPC, being able to write good multi-threaded code is likely to become increasingly important. This is a skill that many programmers seem to struggle with.

Another skill is taking advantage of those 512bit registers (soon to be 1024 bits)
Even with compiler vectorisation, (rarely work) you need to understand the concept, specially around branching.

Ex: writing a line drawing function using scalar operation VS SIMD is dramatically different.

That to say, a single threaded app that is fully SIMD optimize can be faster then a version that is scalar but run on 8 cores.
Now if you get both working together, you get the prize ...

just brew it! wrote:

Waco wrote:

ronch wrote:

...and just can't have enough cores to program for!

Always the goal.

Closer to the truth than you might think. Since we're apparently hitting a wall on GHz and single-core IPC, being able to write good multi-threaded code is likely to become increasingly important. This is a skill that many programmers seem to struggle with.

And with good reason. Finding parallelism, writing for it, and getting the locking model right is a hard problem. The systems for dealing with it "behind the scenes", in much the same way that compilers abstract away the details you need to manage when writing assembler, aren't there yet; Grand Central Dispatch is an interesting take on the problem, but isn't as widespread as it could perhaps be.

Deadlocks, race conditions, locks that block too much ... no, the techniques are not as well understood as they need to be, although I do hope that the situation is improving. Getting your mind around it all is definitely not trivial.

From my personal experience, a good programmer is an architect. The elegance or conciseness of the actual typed code is less important than how the application in general is designed and structured (though a well designed and structured application invariably leads to elegant and concise code). A good programmer doesn't get hopelessly lost in the details; they are able to step back and see the application as a whole from at least 3 perspectives. First, from a perspective similar to a doctor looking at the human body, a web of intelligently interconnected parts, and how they interact with each other to make the organism as a whole work. Second, from the perspective of the user who will use the application and largely doesn't give a crap about the particulars of how the heart beats or the brain thinks. Third, from the perspective of the developers that come after you and whether they will curse or praise you when it becomes their responsibility to pick up where you left off.

Doctor
Does the application meet all user requirements? (or, depending on time constraints, the most immediate and relevant user requirements)
Separation of concerns?
No code duplication?
Is it extensible?
Good leveraging of the application platform?
Is it portable?
etc

User
Does the application do what I want?
Is the application easy to use?
Does the application make my work faster/easier to do?
etc

Next Generation
Is the application easily extensible (this goes back to abstraction, separation of concerns, etc)?
Is the application well documented (or, even better, self-documenting)?
Is the application portable?
etc

Whether you know C, C++, Java, PHP, or whatever, the basic principles of design and architecture don't change. The tools are less important than how they are used (knowing and understanding the principles of object-oriented design is more important than knowing Java or PHP in particular, for example). A good programmer isn't defined by the languages or techniques they know, they are defined by their ability to engineer from the ground up.