What To Do Right As a New Programmer? 662
globeadue writes "My company just tagged me for full time App Dev — I've essentially never coded for money, but the last 3 years of support desk gives me the business sense to know the environment I'll be coding for. Now my company will be training me, so I think the technical side of things will be covered, what I'm looking for is best practices, habits I should/shouldn't develop, etc as I take on my new craft."
Read Risks Digest (Score:5, Interesting)
Read The Risks Digest [ncl.ac.uk] -- it ought to be required reading for all software developers because it is fundamentally about how systems fail and if you don't have a good grasp of how the system you are building might fail, then you will probably build it in such a way that it will fail like a house of cards the first time a stiff breeze blows.
It is low volume with pretty high signal-to-noise ratio so it is not a burden to stay current, and when you have some dead time the back issues - going back for more than two decades now - make for great reading too.
A few tips (Score:5, Interesting)
I'm far from a master programmer myself, but this much I know.
Columbo (Score:4, Interesting)
Find and watch episodes of and old cop show called "Columbo".
Whenever you are unsure of anything, act like Peter Falk's character (Columbo). Whenever you are very sure of something, try even harder to act like that. If things don't make sense to you, ask questions, do experiments, use google, use your brain until they do make sense. And if you have a theory (or a plan, or a piece of code) that you are sure is right, put it to the test.
Don't be a know-it-all, don't blindly assume that you know anything. People sometimes get annoyed at developers who take nothing for granted, but that sort of attitude gets results, so they put up with it a lot longer than they put up with developers that assume they already know everything and project that assurance right up to the point where the project goes down in smoldering ruin.
--MarkusQ
Look for patterns (Score:2, Interesting)
When coding, look for patterns in the code - at the smallest level, anytime you find yourself copying and pasting code without modification, you've identified a pattern and will be better served by extracting that out into a reusable function/method.
You'll find that there are identifiable patterns in all aspects of programming. In the broadest sense, learning how to first identify them, then use them, then predict them is what differentiates a code monkey from a great programmer.
Finally: listen to what your users "mean" and not just what they say. When they try to explain a problem to you, avoid the "works fine for me" syndrome -- remember that they wouldn't be talking to you if /something/ wasn't broken. (Even if 'broken' only means they don't understand how it should work: that could be a sign that how it works is flawed...)
Re:Goto is good (Score:3, Interesting)
Wow. So.. you guys don't write comments because you guys sucked at writing them and keeping them up to date. Is that a fair assessment? Comments are wonderful if used properly, but as you point out, too few use them effectively.
There is a separate circle of hell for those who write:
foo++;
Comments are best used to explain design principles, data models, constraints (if they aren't already coded in), and the purpose of long code blocks - high level concepts that aren't likely to change as the code gets debugged and added to, as well as any code that has to be written in an obscure way for performance. Procedural documentation is best done by the code itself with explicit variable, class, and function names and the like. Even a one-line function used only in one place can be worthwhile if the name explains what an otherwise impenetrable line is meant to do.
Anybody who thinks they are going to maintain detailed procedural comments along with the code either works for the government or hasn't been writing code in a competitive business environment very long.
Re:Goto is good (Score:2, Interesting)
It also makes a nice case statement structure in languages that don't support it -- Perl, for example. Something like:
$self->is_foo ? $self->do_foo :
$self->is_bar ? $self->do_bar :
warn("No match in blah blah blah");
Every journey begins with a first step (Score:1, Interesting)
There have been quite a few good comments here.
Like:
-Don't take criticism personally.
-You aren't your code.
These are all very good comments. I would also like to point out that you are embarking on a long journey. Your not going to become a great programmer in a year. Not even in 2, 3, or 5 years. But you can improve and progress over time. To do that you should invest time outside of work on improving. I would first concentrate on your first language. After that I would start working on theory and some books like code complete, beautiful code, etc as well as reading programming blogs. There is a lot of crappy stuff out there but in time you'll learn how to sort through it which is a very necessary skill you'll need in general.
For theory books you should start earlier then later reading a data structures book. Move on to an algorithms book and eventually check out compilers a bit too. Throw a good design patterns book in there. I've found that the head first design patterns book is really accessible. More so then the gang of four. You probably don't know what that means yet. But if are software engineer for long you'll at least hear that name a few times.
This may seem a bit overwhelming and it is. But all of these things are useful tools. You'll probably never have to write a compiler. But you may need to write something that parses simple code and generates other code.
Simple data structure knowledge is invaluable. You should know the big O notation for all of your basic data structure operations. It is very helpful to be able to recall it like your ABCs.
You should also learn other languages outside of your scope. It'll help you to understand your main language more and probably give you new ideas as well as cement some common programming themes.
Learn how to use more then one operating system. Learn the strengths of weaknesses of each so you can make the right decision when developing and chose the right platform. You can use tools on one to help with the short comings on others. (Insert blurb about basic 'nix command line tools here.)
Next learn some operating system theory. It actually is helpful to learn how operating systems work when you are trying to trouble shoot weird problems.
Like I was saying before this is going to be a long journey. Your working on becoming a professional/craftsman. This will not happen over night or even over the course of a few years. Enjoy your journey.
Some people may scoff at this last suggestion. However, I would suggest going to a real college if you think you like programming. Get a computer science or computer engineering degree. Don't mess with a technical college. They really don't dig as far as they should into theory and won't help you get your foot in the door.
Plus college was a really great experience for me. It opened my eyes to a lot of things in engineering and outside of engineering. Plus I made some great friendships.
Good luck
Re:Goto is good (Score:3, Interesting)
That's a troll, right?
You're fucking kidding, right?
Open your favorite C or C++ compiler. Write the following function:
void blowthestack(int i) {
printf("%i", ++i);
blowthestack(i);
}
Tell me what number you get to.
Stack is very, very finite. And, by the default settings in most compilers, very, very small. Visual Studio 2008's default settings made it to 4713; YMMV.
Left-corner design (Score:4, Interesting)
25 years ago I read a book called Software Tools in Pascal. This had a huge, beneficial impact on me.
The most important single thing I learned from that book is something they called "left-corner design". It goes like this:
Find some small part of your project, preferably something at the lowest design layer. Then code it up and implement it. Make it so brain-dead simple that you can spot all the bugs, and fix them. Now, consider some simple way to make it do something more, something else needed for the final product. Then make it do that, and fix it until the new feature is also working perfectly. Iterate.
As a real-life example, I once made an advanced audio DSP (digital signal processing) engine. It started out as a program that could open a wave audio file, read all the samples, and write them to another file. Then I added a function that could do some simple processing before writing the audio. And then I added some more stuff, and some more, and so on.
As much as possible, make early prototypes that actually do some useful subset of the problem you are trying to solve. If your program will have users, give them early prototypes and see what they say. The Software Tools book had an aphorism that 80% of the problem solved now is usually better than 100% solved later.
You may also find that, as the users try out your prototypes, they may discover surprising things. Perhaps what they originally asked for isn't what they really wanted, and you need to drastically redesign. Perhaps once they start using your prototype, they may invent new features that they really want more than some of the other stuff they asked for.
And perhaps you may get a surprise: "Yeah, we told you you could have 8 months to develop it, but now you only get 4." And three of those months are already used up. The left-corner design hopefully means you will deliver something. And it might just be enough.
The opposite school of design would be to think everything through and plan everything. Hold long rounds of meetings, draw diagrams, that sort of thing. That may actually be appropriate in some industries; if that's how they do things where you work, study it and try to figure out if they have a good reason for it. But even if so, you may need to knock out some sort of handy utility for your own convenience, and left-corner design is the way to do that.
steveha
Re:Goto is good (Score:5, Interesting)
While it's a ridiculous example, someone could easily change
std::string mkdec(std::string x) // Converts x, a string representing a hexidecimal number, to a decimal string.
To
std::string mkdec(std::string x) // Do a little dance, make a little love, get down tonight
And everything would still compile just fine, but all of a sudden new devs on the project are left in the dark as to what mkdec() does without reading through its code. If someone named the function convert_hex_string_to_decimal_string something cryptic or incorrect it would appear in many places (everywhere the function was used) and be much more noticeable and likely get fixed sooner.
Another fun one I've seen in legacy codebases a lot is
//Only used in this place or that place, or for this or that purpose.
int some_func() { blah }
... and that comment was written 5 years ago and is completely wrong. People used doxygen or intellisense or whatever and saw that this function exists and takes the input/output they want but never saw that comment so they used it in 1000 other places.
Or another fun one.
/* function foo()
... big long description of inputs, outputs, constants that affect it, whatever ...
does this, that, and another thing.
*/
void foo() {blah }
... and the description is horribly out of date because it's been changed a million times.
I'll say it again: the compiler can't check your comments, and it's just too easy to change some code that will make a comment wrong and not realize it. So comments have their place but their use should be judicious.
"Self documenting code" (good variable and function names, etc) that the compiler can verify for you are preferable.
Re:Go with the flow (Score:3, Interesting)
My advice to you would be: Stay the hell out.
Seriously, if you're just attracted to programming because of the career opportunities then programming is not for you, and it will make the life for the rest of us that much harder.
You'll compete with people that *really* like to program for jobs, you'll give us all a bad reputation for producing crappy code. The world has too many third and fourth rate coders already for you to think that your support desk background is the stepping stone to becoming a programmer.
Real Programmers (tm) were doing it when they were 12 or 13 (and sometimes even younger) because of a fascination with the tech, not for the money.
ok (Score:2, Interesting)
If you are going to design and implement software components that have any UI in them, please FOR THE LOVE OF DOG do not assume yourself to be a competent GUI designer and expert, just because you know how to spell out language logic into your IDE or WYSIWYG editor. Even if it has a GUI editor, leave it alone and abstract your non-GUI logic so that you can connect it to a GUI later when someone competent in the area finishes one for you.
Awful GUIs as a result of mismanaging priorities and areas of competence are all around us, and I am sure you yourself pondered over few bad examples. Now is your chance to understand the issue and not make the same mistake again.
I presume of course that your are a software programmer, not both (which few people are). You are not your target audience, so if you think an OK button should be to the left, it does not make you an authority in the matter.
When it comes to the rest, most is already said. Observe, be careful in the beginning, design as much but not more than you can in advance, minimize the code writing phase (it will spare you your arms and brain). Do not overcomplicate neither the software, nor the tools you will use to create the product, tools like IDE, compiler, UML editor if any, etc. Do not overuse the abundance of choice you as a software developer have. The most useful software is very simple in the sense that it achieves its goal exactly, no less, no more. You will be thanked for that more than you will know. Read books, as much technical as wisdom-and-guidance sort. But reserve an opinion, it is what makes you an unique programmer, not just a typewriter monkey. Be skeptical meeting the type of programmers that try to convince you about some definite programming practices they sincerely think are best. Heed to their wisdom of experience, but reserve an opinion. Value practical code over theoretical approach, because it is the real products we use, not theories. But do not reinvent the wheel, most theories have been implemented in practice, and it is what makes your life easier.
Remember, the most probable goal of your company is to make money, so that you can get your salary and your boss may buy himself a new wristwatch for 2 grand and pay ails to his ex-wife. Combined with the fact that most folks that comprise the bulk of an IT company would not know half of what you will know about IT internals, they will ignorantly still push their own ignorant agenda when it comes to the style of product. It is your job to provide them with the necessary insight so that product is quality, not just a seller. Adobe Photoshop may sell well, but it is in absolute sense a mediocre product.
Thanks for reaching this far.
Re:Education (Score:3, Interesting)
Yeah , of course you did sonny. That'll be why you know all about Phong & gauraud shading, DB normalisation and tuning, digital signal processors, AI vision algorithms, network theory etc.
Because I did all those for my BSc.
But i'll admit , if all you ever do is write mickey mouse VB apps for a living you won't need any of the above.
Re:Always think about maintenance (Score:1, Interesting)
"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." â" Brian W. Kernighan
And a personal favorite:
"Always code as if person who is going to maintain your code is a maniac serial killer and knows where you live." - ??
Humility (Score:2, Interesting)
Few are, and the real experts are usually the humble ones you don't know about until you actually work with them.
Find those people. Emulate them, befriend them.