What does it take to be a real programmer?

When what you want can be done simple, don't make it hard on yourself just to look smarter. Most often the smarter programmer's code looks neater and is easier to read.

Thank You.

Actually, that helps a lot. I know that I could get stuff done fast, and it would work correctly. However, I try to do things in a way that makes me look more professional then I am. I want to try and know everything there is to know about programming so there is no question I cannot answer just because it makes me look smarter.

Maybe I should stop taking for granted what I do have, and realized that although I may not be the best programmer in the world. I am pretty good, and I have a skill that most people don't have. A lot of people have problems just using a computer. I should be thankfull that I understand them well enough to program them.

I think I am a good programmer, I'm just not the best, and I don't know everything so that makes me lose confidence in myself. I see to many smart people around. I also see a lot of other people just like me, who try to answer every question even when they really have no idea what the answer is, just because it makes them look smarter then what they are.

Just because I don't know how to write my own operating system, or my own graphics programs, like Photoshop, doesn't mean I'm not good at designing business software.

I just thought about it when I was watching TV. There are a lot of Doctors in the world. Some are better with kids, others are better in the ER and others in the surgery room. Just because a doctor that works with kids can't do a kidney transplant doesn't make them any less of a doctor. They just have different skills.

I spend a lot of time formatting my code with tabs, and making it the best code I can to get every single speed increase that is possible. I have been told that I waste too much time with it. I think I just love programming and I consider my program to be a piece of artwork. Not just something I do to pay the rent.

Thanks alot, you helped me get a different view on my skills. I always looked at what I didn't have, when I should have been looking at what I do have. :)

Sometimes I spend more time on the formatting of my code then I do with the actual design of the entire solution.

I am proud of the programs I make, and I like to make them look nice. I don't get obesssed with the formatting, but I like them to look good.

I doubt very much that anyone can say that they are the best programer in the world, I have several programmer friends and each of us have a certain field with in programming that we are good at.. Some excel in the Graphics area, Some in Logics, Some in the Maths, One mate of mine cannot write a full program, yet you hand him a app and he can debug it and give you a proggy that runs 50% faster, and cleaner.. He cannot find his own methods to complete a task, But give him a method and he can find a quicker / easier way to do it..

Another guy can write long lenthy programs that do the job, but always seems to reinvent the wheel when he does it.. But he found solutions when others got stuck..

The abbility to put code together to complete a task makes you a programmer.. The abbility to make sence of someone elses code and write it better make you a good programmer..
The abbility to use multiple languages and understaning all fields (math, Logic, Graphic, User interface, etc..) make you a great programmer...

Me personally, after 20 years of programming am a good programmer..

but we all strive to be great..

Gremmy...

I nearly skipped joining this thread, but I re-read theHobbyist's original question.

The phrase 'real programmer' - akin to 'real man' or 'real cowboy' - nearly turned me away. That's before I noticed the genuine interest wasn't about the common competition we males engage in of 'who's got the biggest' - but instead, it was a genuine inquiry about the craft and where each of us fits in, either in a professional or personal way.

I found a lot to like in several of the posts appended. I recall grappling with this question about myself some 27 years ago.

In the move "Something the Lord Made", the story of Vivien Thomas and the first heart surgery, the life and career of Dr. Thomas illustrates this notion in the subject of a 'real surgeon'. Vivien was not educated as a doctor, but as the story reveals, he was part of a team (of two) who created a new way of thinking about surgery on a previously forbidden subject, surgery on the heart. He was eventually awarded an honorary doctorate, but he had been a real doctor for many years.

I consider myself a real developer/programmer/engineer - whatever the term ought to be. I've developed applications ranging from 3D graphics, 2D image processing, manufacturing robotic systems, business applications - I make custom controls on a whim, I write for any operating system - will use whatever language is required, though I'm partial to C++ (rather heavily). It's been years since I've attempted something I wasn't certain on how to proceed.

There's a place for practitioners of most of the skill levels, and plenty of snobbery about those with considerable experience over others, and between fans of the various languages (especially Java/C# vs C++).

Let me take points from theHobbyist for elaboration.

I am pretty good at writting concise/fast code and creating business applications. Like customer and account management stuff. But I have a hard time when it comes to overriding prebuilt classes, using GDI+ and creating my own user controls for applications.

For years I worked in 'the corporate world' - it was a major retailer's headquarters - nearly the entire decade of the '80's. Most of what they wanted was exactly this - customer information systems. I used to call them 'bag of fields' applications. Although the technologies used today didn't exist then (even C++ didn't exist at first), the corporate climate is similar, the needs are similar - just the means have changed. Your C# knowledge is applicable to this kind of work.

I was among the very first to deploy PC's in companies of that size, and for a while many of the IT experts there thought I was nuts (talked behind my back, tried to undermine my work, etc.). At that time the IT department was 'a mainframe' - used reel-to-reel tape drives for backup (that don't hold half what a CD holds) - they just thought it irresponsible to put 'toy computers' in charge of data. It took only 4 months to convince the 'non-tech' VP's I was right, because I saved them big bucks. Within 4 years, IT moved out of the building, out of state. Virtually everything smaller than taking input from every one of the 10,000 cash registers (still the mainframe's job) was taken over by my 'toy computer' department. At the time I left for bigger fields of play and work, the 486 CPU was just being released. Today, even I would consider the machines I used back then to be mere toys, and yet, I managed to handle an inventory database of 4 million records - printed reports of 50,000 pages within 24 hours, served thousands of users.

Today, those tasks are managed by C# programmers, perhaps Java programmers, and in the not too distant past, Visual Basic programmers. Then, too, there's probably a mix of web-based interfacing in the mix, too.

But as you point out, this isn't the kind of 'engineering' required to build custom controls, or work in even deeper fields of study.

I was told that there is a difference between someone that can write a good business solution and someone that can write a good control to be used in the solution and that they are two different skills. One might know a little about both but usually is an expert in one area only.

...well, frankly, I'm very experienced in both of these areas, but I'd probably avoid writing the business software these days - I'll explain a little more later. These are definitely a different tasks. There are examples of business solutions that hinge on the esoteric. Scheduling is one. It may seem at causal observation that scheduling is little more than making a calender program, but in fact, GENERATING a schedule for, say, manufacturing, given a set of constraints, due dates, complex manufacturing processes, raw materials supplies - it is actually one of the most complex problems to which computers are addressed. The study is not far from (in detail and complexity) to, say, weather simulation.

Custom control creation is fairly standard Windows programming usually, but it's 'black art' stuff to anyone not familiar with it. Game simulations involve some of the most sophisticated development strategies in all of software development.

Does someone need to know and understand all areas of a language and also very advanced techniques before they are considered to be a real programmer?

Probably not, but then it may depend on what targets you're addressing. The 'bag of fields' targets require a set of skills quite separate from making, say, a SQL server engine, even if they both address business data. There's more 'science' required of someone making a SQL server, and since it's likely going to be C++ (or C if it's an older codebase), very deep understanding of all aspects of the language would be required. I wouldn't say either should be disqualified for the title 'programmer', but then both a family physician and a surgeon are properly referred to as 'doctors' aren't they?

From what I understand most of the predesigned controls in the toolbox are designed from Win32 (what ever that means) and that it can be extremely complicated and advanced topic for someone to successfully override these controls, or draw their own controls from scratch. Most people that need to make their own controls use a UserControl to "build" a new control. Instead of drawing them from scratch by their self.

Anything that has WM and Extern or import user32.dll type code completely confuses me. VB6 was my first language and then C#. I know nothing about what all this WM, etc... means.

For Windows development, the standard controls found 'before' .NET was invented were written as part of the operating system. Controls like the standard button, the edit control, the list box, etc. are part of what makes Win32. Win32 is the set of functions exposed by Windows as the operating system - all of the 32 bit versions of Windows are based on the Win32 API. Each of the versions, though, have their own extensions or limitations.

Creating your own control isn't all that complicated, really. You are dealing with the operating system's construction, the nature of messages sent to your code as events, but it only takes a month or two to get the hang of that. For example, WM_PAINT is a message sent to your code if something has happened to cause Windows to 'think' your window needs repainting. You respond by making a 'paint' function, drawing what needs to be displayed, and exit. That's about it. There are hundreds of messages, true - but most follow a reasonably logical pattern (though some, I must admit, leave me wondering why the designer's chose to do it some particular way).

Linux, when paired with a GUI subsystem like X-Windows and/or KDE, has something very similar. Different in the particulars, but similar in the overall concept.

Messages are used to inform an application of keystrokes or mouse motion/clicks and similar 'events'. The task of creating a control is to figure out how to 'animate' a control using these events, and the other tools available to you for drawing the 'metaphor' of a control.

I am pretty good at writting programs, but I sometimes have a really hard time reading programs that were designed by someone else. I am wondering if this is common in all programmers, or if it just means I'm not very good.

Join the club! This is why it's important to follow coding standards, any standard will do, as long as it makes clear what you intend.

Not long ago I grabbed a copy of the free JPEG library - it's code to read and write standard JPEG files. It's terse code, very technical stuff regarding the encoding of JPEG images, color conversion - much of it poorly explained, in my opinion. It's tough to follow along. It's tough just to figure out what one is expected to do with it.

On the other extreme, I used a framework called wxWidgets. It takes the place of MFC if you want to make C++ applications that can be compiled for Windows, Linux, Apple and a host of other 'devices' - like smart phones. I find it rather readable code - it's not as terse, it's written in a clean, fairly good style.

I have been thinking about going back to school and getting a professional career as a real programmer, I am a very analytical type person, but I have a hard time learning things from articles, and books. I need someone to show me personally, but then I am really good at it once I learn it, and I learn really fast.

For this particular field, you really need to discover within yourself the ability to learn on your own. I don't disagree with the notion of returning to school for the study - it's a good plan. However, since I've been out of the 'school age' years for quite some time. I must remain current with the industry, I couldn't manage to do that by returning to school.

However, reading a book isn't quite the method, either. Experimenting is the real key. If a book covers a topic, it won't settle in the mind until you get your hands on the keyboard, your mind wrapped around the puzzle, and work it within your own thoughts. Nothing else will quite do the trick.

When DOS was still 'king' of the PC world, and the SVGA was the new king of graphics, I spent weeks reading through Ferraro's text on programming for it. In DOS, you had to, essentially, write code that sent commands directly to the graphics card. You might have a 'graphics' module for your compiler (Borland had such a thing for Turbo C and Turbo C++), but if you were going to get really good results, you had to write to the card yourself. This was assembler level stuff - you could work in C or C++, but you had to get right down to the hardware.

I kept the book with me everywhere, read and re-read the sections, toyed with it in my mind, considered just what was being discussed - and read material from related texts on general graphics concepts.

One of my goals was to create an application for a manufacturing target that could display text to the 'mechanic' working on the shop floor, and show diagrams from the engineering drawings - but to do it fast, on 286 computers. This was no small feat.

Once I tried it, and I had to try it a few times to get anything functional, it began to make sense. Reading it was one thing - I could almost recite pages of the text, but still without 'getting' it. It was when I tried to do what was being described, and worked myself out of confusion, that it finally sunk in.

That's something to keep in mind. You can expect that the state of mind you will experience just before you understand something is confusion. There simply is no other way. You have to become accustomed to that, let the unknown parts remain like variables in an algebraic equation, which you'll solve later as you progress through the material. Keep reminding yourself, this stuff was meant to work, and someone understood it - you probably have the same mental ability as they did. How many times, already, have you looked back at something you didn't understand only to consider it trivial now?

It's wonderful to create machines out of words and logic. It's a great feeling to discover something you've made has been a part of other people's daily work day, to observe that your creation doubled productivity, helped a company grow and hire more people. It's cool to hand a solution to someone who's been stumped on a problem for two weeks, and help them jump a hurdle that otherwise stopped them from their own important work.