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."
Go with the flow (Score:5, Insightful)
Well, I think you'll probably pick up those best practices as part of your "training".
Every shop does things differently.. from simple stuff like naming conventions right up to core design methodologies and team management.
My advice would be to just spend as much time as possible listening and observing. Read through existing code.. pay close attention in meetings to how the brainstorming and final solution tends to evolve.
Some companies take a "we are paying you for your intellegence.. part of your job is to argue your design and beliefs" attitude whilst others take more of a "we are paying you.. so shut up and do it the way we want" approach.
As a side note.. check out the book "Beautiful Code"... It's good mind food. "Pragmatic Progammer" is also good.
Always think about maintenance (Score:5, Insightful)
Probably the most important thing you can keep in mind when writing new code is to think about the poor sap who has to maintain that code somewhere down the line. Especially because in a lot of cases, that poor sap will be you. Pretty much everything else follows naturally from there.
Re:Go with the flow (Score:5, Insightful)
I agree to an extent. As a new developer I think it's important to listen to more than one source. So listen in training but also be skeptical. Try to find other sources for claims.
And as for my book recommendation, I suggest "Code Complete"
Re:Goto is good (Score:5, Insightful)
Experiment and dabble in other languages (Score:5, Insightful)
Listen, think, and listen (Score:5, Insightful)
- Listen to your end users. They're the reason you're writing the software. Even when they ask for something stupid, be sure to listen to their needs.
- Listen to other smart developers. Find the smartest experienced guy in your new team, or other similar teams, and pick up tips and feedback. There is a LOT that can easily be learned from other smart people's experiences. Ask questions, but don't be annoying. Following a few bloggers in your field can be helpful if you find the right ones, but an experienced person on your own team would be best.
- Read up on general best practices [docforge.com]. Indent your code consistently, write comments, name variables and functions well, etc.
- Think about your code long term. Code is rarely used just once and never looked at again. Write it so it should last and be relatively easy for you to pick up a year later or for someone else to take over.
- Don't box yourself into one line of thinking. If you become religiously attached to one particular language, for example, you'll eventually stagnate. Learn the best traits of a variety of languages and systems. It'll make you a better all-around programmer.
Comment removed (Score:5, Insightful)
Re:Goto is good (Score:4, Insightful)
?: ternary is fantastic for short clauses, such as $foo = isset($_GET['id']) ? sanitize($_GET['id']) : 0;.
The logical sequence for this is a and b or c, or isset($_GET['id']) && sanitize($_GET['id']) || 0;, but ignore the PHP 'cause PHP won't handle it this way (it'll put a boolean in $foo).
Some advice I've learned (Score:3, Insightful)
2) Never blame someone else directly, even if it is obviously someone else's fault
3) Don't expect overtime pay. You'll never get it. If you ask for it, things will conveniently become a "this isn't working out" situation 4) The salesmen will sell things that you probably can't provide without working 24/7 for the next 6 months. They will also likely make 4x what you make, plus commission. Bend over and take it. 5) Do NOT EVER NEVER EVER bring in personal code to work... even if it suits the situation/project. Not only will you be expected to then provide some more goodies in your off-time, you pretty much lose the right to it of any legal ambiguity occurs. 6) Get every promise in writing. Whether it a bonus, "comp time" for late/extra hours worked, whatever.
Comment removed (Score:5, Insightful)
Re:Goto is good (Score:3, Insightful)
This is one of the times when the saying "there is more than one way to skin a cat" comes to mind.
I work in a shop that has a solid rule of not commenting anything. It carries another hard rule along with it. We write very explicit method, field, parameter, and test names. If the code is in someway not understandable for you than stop and rewrite it so that it is clear.
Comments are a nice concept, but in practice they are rarely kept current. And amazingly enough are rarely correct immediately after they are written.
Sometimes there might be a better way to do things.
Write good descriptive comments... (Score:5, Insightful)
Try to right program code comments as much as possible as long as memory permits it (if you do have a memory cap).
It makes your job down the road a lot easier, as well as other people's job easier, too.
Try to have it make sense, too. Overall, doing this helps you in retaining how the code works step by step so that you will almost know it like the back of your hand.
Goals, motivation, and good music (Score:4, Insightful)
So far I like mr_mischief's reply [slashdot.org] best. Aside from that, here's what keeps me on track:
But much more importantly, get enough sleep. I'm at least x2 more productive when I have 8.5 hours of sleep than when I have <7 hours of sleep. That's 1.5 hours that makes the difference of +4 hours of useful work. It's worth it, if you care about your work at all.
- shazow
Re:Some advice I've learned (Score:3, Insightful)
1.) Asks you how long you believe something will take and then actually listens to you, and more importantly won't punish you if you were wrong. (Though it is important to tell them as soon as you know were wrong.)
2.) Maybe people could actually just volunteer and say "I screwed up." when something comes to light? No need to blame period then.
3.) Overtime pay is completely dependent on what you agree to when you are hired. And if they agreed to it, and still won't pay you, then you don't want to work there.
4.) Or you work at a place where the salesman have a good relationship with the development team. And like above will talk to them about how long things will take and set priorities appropriately.
5.) Don't bring your own code in, but still keep coding in your off time. You learn from it.
6.) Any place you work should give you in writing what they ask to include. If they are out to stab you in the back you don't want to work there.
Not everyplace out there is a hellhole. It took me a while to learn this too, but there are legitimate good places to work. Find one.
Re:Go with the flow (Score:5, Insightful)
Great stuff. Find a mentor. Most technical classes focus on how to use the language, never how to use it right.....at least not until you get to the advanced classes, which as a new dev, you aren't ready for. The best place to learn these things quickly is to figure out who in the group knows what (and is friendly/helpful) and glom on to them. Become their friend (bribe them with caffeinated products) whatever it takes. And absorb everything you can from them. This will usually take more than one expert (best design guy, best coder, best db guy, best politics guy). Just don't be a pain about it....if they explain something once, write it down and don't ask them about it again except for further clarification.
I love taking people under my wing and helping them grow, but if they keep asking the same questions, I see that they aren't trying to learn anything and just trying to take advantage of my knowledge. I still help those people for the good of the team, but usually with "here's your answer, now go away" approach instead of the "here's your answer, oh, and here's a better way that will make you a better programmer" approach.
Layne
Re:Exceptions! (Score:4, Insightful)
Lies. Exceptions are not meant for intentional flow control, they are for exceptions. Exceptions are (in almost all implementations) much slower and you would never want to use them in place of a goto in, say, a core loop where the goto case happens a significant portion of the time.
(1) "Don't fuck up", (2) mentor, (3) balance (Score:2, Insightful)
Same could go for software development.
Re:Goto is good (Score:2, Insightful)
Judicious use can make code clearer. As Mum always says, everything in moderation. (That is where the emphasis is, right?)
a couple things (Score:3, Insightful)
1) go buy code complete. read it a chapter a week. when you are done, reread it. if your understanding of the book has not changed completely, you need to go find a new career.
2) learn discipline now. code complete has some excellent examples (e.g. declaring variables only as you need them and initialize them immediately, put constants on the left hand sides of logical tests, etc.) and your coding standards should provide other guidance.
3) take dijkstra's words to heart: "The competent programmer is fully aware of the strictly limited size of his own skull; therefore he approaches the programming task in full humility, and among other things he avoids clever tricks like the plague." corollary: "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." (kernigan)
4) get in the habit of maintaining engineering notebooks. over time you'll figure out how to keep useful notes and those notebooks will be worth their weight (or more!) in gold.
5) go find a senior dev that you have a solid personal relationship with and see if you can establish an informal mentor/mentee relationship.
6) ask questions. lots of them. keep on asking until you're satisfied with the answer.
7) understand that any task that requires more than 2 minutes worth of programming merits at least 10 minutes worth of putting a plan together / drawing pictures / planning and at least 30 minutes worth of testing (ideally by adding to an existing automated test suite, hint hint...)
Re:Goto is good (Score:1, Insightful)
[snip]...Please please please, leave comments so others can figure out what the fuck your logic was...[snip]
Just elaborating on that - write comments that explain _why_ you're doing something not _how_ you did it.
It's much more useful to see why someone did a bit of code in a particular way than it is to have an explanation of what the next 10 lines mean. Programmers can work the latter out if they need to.
Re:Document your code (Score:4, Insightful)
Unfortunately, test-driven design is not a silver bullet, unless you're lucky enough to have a finite problem space where you can achieve 100% test coverage, which almost no-one does, and you can consistently write perfect test code, which would be surprising if you're worried enough about your normal code to write all those tests in the first place.
In the absence of such unrealistic guarantees, TDD lies somewhere between a useful addition to your coding practices and snake oil, depending on the realism and honesty of the person advocating/implementing it. Either case, it is not a substitute for good documentation and commenting.
Re:Goto is good (Score:5, Insightful)
I strongly agree. Self-describing code is much better than comments. Comments are only useful, IMHO, when you need to describe a complex situation. If it can be expressed in one sentence or less, it should probably be part of the code itself. I.e., instead of:
std::string mkdec(std::string x) // Converts x, a string representing a hexidecimal number, to a decimal string.
std::string convert_hex_string_to_decimal_string(std::string hex_string)
The latter says the exact same thing, but is far likelier to be maintained properly. Also, if you get in the habit of coding like that, you never have to worry about forgetting to comment. Furthermore, the "comment" is effectively replicated every time the function is used. Hence,
instead of:
hex = "0x" + number_str;
return mkdec(hex);
you see:
hex = "0x" + number_str;
return convert_hex_string_to_decimal_string(hex);
Now, if you had a function that implements a complex algorithm that can't be summed up in short order, then sure, use a comment. But in my experience, 95% of comments in code are like the above "mkdec" comment, and would be better expressed just by using a more descriptive function or variable name. I think a lot of coders are just lazy and don't want to have to type in longer, more descriptive variable and function names.
Re:Worst commenting i ever saw (Score:4, Insightful)
Actually, I've been told that assembler code ought to be commented in just that way. In well written high-level code, individual lines should have a self-evident purpose, but often this is just not possible in very low-level code. Can you really tell at a glance what "djnz" means? And even if the answer is "yes", can you reasonably expect everyone else to have it memorized?
I don't have enough experience with assembly language to render an opinion myself on whether this is really necessary in a development context, but in school I spent a semester programming ASM and the line-by-line commenting seemed indispensable.
(Or did you mean that the comment was somehow inaccurate? Like I said, who can look at "djnz" and remember what it means? I can't.)
Use a slow machine (Score:5, Insightful)
Use a slow machine with little free memory to test your code. It teaches you to be efficient. That is why 1GB of ram is not enough for an office anymore.
Re:Always think about maintenance (Score:5, Insightful)
There's a famous epigram (hopefully someone can provide it) to the effect that it's twice as hard to read code as to write it, so if you write your code as cleverly as possible, you will most certainly be unable to read it.
If you're proud of a clever solution and can't wait to show it off, then it's an unsatisfactory solution. The best solution to a difficult problem is the one that is so clear that after reading it, nobody can comprehend that the problem presented any difficulty in the first place. The sign of a really great programmer is that he never gets stuck with any difficult projects. Everything assigned to him turns out to have a simple, easy solution -- what luck!
Education (Score:3, Insightful)
No matter what more politically-correct people like to think, all people are not born equal. The best software developers are born with a certain affinity for the mindset required. Education can build on it, but if you don't have it to start with you won't ever be good or as happy working as a software developer as whatever you're really cut out to be.
You need to make an analytical and honest decision with yourself as to whether this is a direction you want to be going in with your life and career. Unless you're absolutely sure you're the right person to be a software developer, then don't do it. The fact that you've apparently already been happy to do tech support rather than write software might itself be an indicator that this is not a good move for you.
OK now you've decided to go ahead anyway, the next stage is that you need to know what you are doing.
Contrary what most other posters here are suggesting, you're jnever going to be fully effective if you just try and learn on the job or learn from other software developers around you. There is a lot more to being a good software developer than being able to write a program that runs OK.
By limiting yourself to learmning on the job, at best you will only develop a tiny subset of very specific skills you need for your particular company/product/langauge/toolchain, and will not get a deeper understanding of some very important concepts. Also that approach will almost certainly start you off with some very bad programming habits (i.e. your colleagues).
Ask your company to allow you as much time as you can get to attend some Cumputer Science and Software Engineering courses at your local college or university.
If you need justification, tell them that your company will save way more than the time/money it costs them in terms of your increased knowledge, usefullness and code quality meaning much less rework required.
If they still say no, then make every effort yourself to at least do some evening courses and build points towards a Computer Science or other similar software related degree.
Assuming you don't want to work for the same company for ever, you need to understand that no matter how good you think you are, these days a Computer Science or other relevant degree is a basic requirement for many if not most software developer positions. You learn a lot of really useful fundamental concepts on a CS degree course that will be highly relevant, used and needed throughout your whole career. Ususally the only people who dont agree with the value of a CS degree for software engineers are those who don't have one, so don't know what they don't know.
Two Rules (Score:2, Insightful)
1) do anything that makes you want to write code
2) don't do anything that discourages you from writing code
Coders cease to be coders because they fail to follow these two rules, and many find themselves in marketing or customer support. Some even wind up in sales.
Re:Goto is good (Score:4, Insightful)
I want to make one point. *any* code is unmanageable if you don't comment
I disagree strongly. I think the important thing is to make your code easy to understand. Comments should be a last resort.
As an analogy, consider your MP3 player. Suppose that every time they struggled with a UI decision, they just decided to put something in a manual or on a sticker on the back. It would be an abomination. The right approach is to make it so that as much as possible, instructions aren't necessary.
When I'm coding, I'll first try to put information in names, like variable and method names. Next I'll try to extract methods or objects, so as to minimize complexity. Then I'll worry about interface and object names. And I put a lot of information in readable unit tests, as that's a kind of documentation that the computer can verify still is valid. Documentation is always a last resort.
I have to deal with a lot of other people's code, and I'll always take beautifully polished code with no docs over mediocre code with lots of docs.
Re:Goto is good (Score:3, Insightful)
Disagree...
Commenting should be reserved only for especially complex algorithms (describe the algorithm itself) and class level descriptions (what the class or module does). Decipherable code has much more to do with good variable naming, good indentation habits, and consistent well thought out use of flow control structures.
I can't count how many times I've been tripped up by a 'helpful' comment that had been left when code was refactored or changed over time. Dangling comments are a real problem. It's one thing to have to actually read the code (a skill good programmers universally have) and another to have a comment tell you one thing and then have to grok that the code is actually doing something quite different.
Re:Go with the flow (Score:5, Insightful)
Keep your reading up, and buy those books.
Keep a register of absolutely everything anyone asks you to do. Number and date each item. If you don't have access to a help desk-style problem registry then build your own. Make it quick to use. Notepad works. Spreadsheets a little better. BMC Remedy or HP/Mercury Interactive if you're spending someone else's money. Besides being good organisation, it's a serious cover-your-tail survival bonus.
Make your code clear. You want it to be so easy to read and understand that you can debug it over the phone in a new year's eve party if you have to. (Yes, I've had to.)
Comments first -- if you can't explain it in English, you probably don't have a handle on the problem yet. If you're chasing your tail and can't get that loop to work right, throw the code out and re-write it in English. Then try coding it again. Remember that English, your natal firmware, has been debugged over the course of your entire life and is still the highest bandwidth channel to your brain. (If you can write correct English, of course. If you don't, treat it like an essential coding discipline you have to learn.)
Be careful with your code libraries, and avoid bloat. If you're sorting a customer's web shopping basket, consider writing the sort yourself rather than including 200k worth of otherwise unused code. Even the lowly and properly-maligned bubble sort is better than that.
Conversely, never write your own little calendar applet if you can grab the code off the web. Plenty of work out there without requiring everything to be crafted with your own unique style.
Never, ever code when you're tired, you will break something. Caffiene is for the smiley boost during the work shift, doesn't cure the 10th hour stupids.
Disclaimer -- I've been a programmer for nearly 40 years, so I'm probably a stupid old person now. You're allowed to ignore the above (heh heh).
Reduce Complexity (Score:2, Insightful)
Always keep in mind that your job is to reduce and manage complexity - not to increase complexity or let it run wild.
Seek out ways to make your code simple and elegant.
A large part of complexity management is making sure that your code can be read easily, and that it's function is obvious from a quick scan.
Find good code (this may be difficult), and read it. You'll notice things including:
- short functions / methods
- each function / method does one thing, and it's name clearly tells you what it does.
- simplicity and understandibility is favored of 'trickiness'.
- in the words of the "Pragmatic Programmer" folks, the "Don't Repeat Yourself" (DRY) rule is followed.
One more thing - don't fall into the bad habit of "I'll do it this crappy / complex way now, and refactor it / comment it later". In practice, "later" rarely happens.
Re:Worst commenting i ever saw (Score:3, Insightful)
No, hell no! I program in assembler (on zSeries). DJNZ and such are easy to find in the manual. Whoever reads the code is expected to know the instruction set.
I would recommend to comment on (almost) every line, but the comments have to be meaningful. For example, instead of saying "increment register AX" say "increment file array counter" or "point to next character", depending on what you are working with. It's extremely important for readability to constantly repeat what kind of data you have in registers. Or if you are testing a condition, write what condition means - is it error processing or normal program? Where do you jump? And so on.
Of course, you should also use comment blocks for larger algorithmic structure of the assembler program.
Read the definitive references (Score:4, Insightful)
Find the most authoritative reference manual you can find for every tool, every language you come in contact with. The question is not "how do I make it do such-and-so?", the questions are "what is it made to do?" and "what can I make it do?".
Do the onion-skin trick: read -- almost skim -- once, for fast comprehension, don't try to remember everything, just remember the new words and where to find them. Read it again, to remember which parts talk about which other parts. Read it again, to start understanding why those parts talk about those others. Only then should you even start thinking about asking yourself "how do I make this do X?".
Don't trust *anything* in any other book until you can tell what part of the authoritative reference it's talking about. Using C++? Pay the $18 or whatever it is now and read the ISO standard. Every book about C++ you read, tie what it's saying back to a section of the standard, and be sure you understand what both are saying. Using vim? Read the help. All of it. Do it again. Using MS Word? Hit F1 and start reading. Read everything. Using Python? Get the reference manuals and read them. Using TCP/IP? Read the RFCs.
Read The Fucking Manuals. Obsessively. Reread them again a month later. Then again a few months later. The questions are always: What is this made to do? What can I make it do?
Get used to it. I used to tell people I read manuals for a living. Classes are excuses to spend that much time reading the manuals. If you read the manuals, you won't need the classes. There is an *astonishing* amount of crap out there in the help books, useless "simplifications" that obfuscate the point of what they're supposedly explaining.
What worked for me every time I had or could steal the necessary time was, roughly, to overengineer the hell out of it, then boil out all the crap. Antoine de Saint-Exupery's maxim is absolutely dead-on: Perfection is achieved, not when there is nothing left to add, but when there is nothing left to remove.
With a little practice, most of the overengineering and boiling-out parts can be done in your head.
Particularly while you're new, reread your old code, constantly. Go find things you worked on before and read them again.
Re:Worst commenting i ever saw (Score:3, Insightful)
OK this is just flame bait. There's no DJNZ instruction on the x86. Even if it were a macro, you don't put the colon on the reference to a label, only its definition. Which only goes to show: YOU ARE NOT AN ASSEMBLY PROGRAMMER. It's not your fault, you could have been, but you just aren't. I'm so sick of hearing people gripe about the supposed unreadability of assembly code only to find that they're totally unqualified to be touching it in the first place. I can't make head or tails of most Java code either but that's hardly surprising since I don't know Java. Whose fault is that?
Not to say that the code you were looking at wasn't crap code, but I think you're missing the point. Assembly language (as written by grown-ups anyway) typically has three levels of commenting. The line-by-line stuff is absolute nuts and bolts and sometimes does get a bit inane (it certainly shouldn't be explaining what the instruction names mean since assembly programmers already know that, but it's there to walk the reader through the math etc. and keep track of what's happening in the registers), anyway it's really just there to make sure the low-level logic is totally transparent when you're zeroing in on a modification or bug fix. Until that point you don't even look at the line-by-line comments.
Then there will usually be a line or two at the top of each code block saying what the next chunk of code does at a higher level. And then each subroutine has a block comment at the top that explains the whole thing and how to call it and what it returns and how it reports errors. Or if not, fire the programmer!
Typical C programmers tend to see assembly code as hopelessly overcluttered with comments but, don't get me started on typical C code. It's a cultural difference I guess. All the more reason to specialize.
Re:Take some classes (Score:3, Insightful)
as a "cowboy coder" (for the most part), I'd like to pipe in: ignore everything he just said.
The only way you will ever be any good at programming is by teaching yourself, writing code in your free time, learning everything you can outside of a classroom. AND outside of work.
Too many people think that programming is something they can pick up by taking a class. I've met the results and it's not pretty.
More importantly: You do NOT need to understand the implications of any low-level operation, because as a Jr. Programmer you should not be the one making those decisions. Premature optimization leads to bad code, and too many new programmers focus on things which they are not qualified to write, or have no business writing. (I have yet to encounter a real-world situation when I have needed to write my own sorting function, hash table, or non-basic tree structure)
Always remember that for all things, someone has already written exactly what you are trying to write. Simply because it already exists, it has had more time than what you are writing has had to work out the bugs. For the love of god, don't write your own "database abstraction layer". Always assume that for any task, someone else knows how to do it better- and collaborate with other people constantly to find out how that is.
People who "aren't trained in programming", but program in their spare time are ALWAYS going to be better at writing code than people who "are trained in programming", but have never written a line of code outside of school or work.
Re:Go with the flow (Score:3, Insightful)
I really hope that, one day, writing code like that will be a capital offence. Sometimes I just wonder what's going on in the heads of people who write code that way. Don't they ask themselves why their code doesn't work well? It didn't work well, did it? Unless if it was a small application, code written like that is guaranteed to be full of bugs.
I recently saw a very interesting webpage (I've even printed it out) about coding: http://bsolano.com/ecci/ci-2200/artu/ch01s06.html [bsolano.com]
In 11 pages, it condenses a lot of the knowledge you learn after programming for 20 years. Very, very interesting.
The rest is discipline to keep your code clean and well documented. Also, if you don't feel 100% comfortable with how you are going to implement a function, write the function comment first and describe what the function does. I found that by first writing it down in plain text, it becomes easier to transform the idea into statements. It's tricks like that you'll have to learn.
Re:Exceptions! (Score:1, Insightful)
How well do you know exceptions in Java? I haven't tested it myself but read a thread on a J2ME forum in which somebody showed how it is faster to iterate an array if you don't do bounds checking yourself but instead simply catch the ArrayIndexOutOfBoundsException because Java checks it anyway and while (true) is fast. People there perform plenty of such tests when they try to optimize their mobile phone games - and gladly admit that it requires some horrible coding practices.
Re:Go with the flow (Score:5, Insightful)
Then again, what books to read as programmers can be a whole other post,in fact I think it's come up.
Yes, but the general principle of "keep reading" is a good one. Read code. Read books (online or dead tree). Read articles. Read about new technologies, new approaches to old technologies, innovative solutions, successes, failures, pretty much anything. The person who stops doing background reading once they can do their job is a person who stalls and gets left behind. Do read critically, though, and remember Sturgeon's 2nd Law ("90% of everything is crap") -- there's nothing (well, not much) worse that someone who wants to overhaul the complete development process just because they read a magazine article about a new approach that promises to solve all the problems of everything that went before!
Code should be readable without comments (Score:2, Insightful)
Re:Go with the flow (Score:3, Insightful)
I've been a programmer for 45 years, so I am definitely a stupid old person now. Nevertheless, for what it's worth, I endorse the above advice.
Abstract/Generalise (Score:2, Insightful)
Don't go Overkill,
But if you have to copy/paste a section of code > about 6 lines, it should be put into a Function/Procedure that is globally accessible.
There's nothing worse than finding a bug in a section of code & realise it's in 10+ different places.
Name Functions/Procedures something suitable, readable code will help you & others. (same for variables, unless its obvious).
Rest is pretty much depending on what language ur coding for. I assume its OOP (of some sort).
Another pair of eyes (programmer) is sometimes good as well, another person may think of another approach etc.
And always if in doubt, use google... :)
Describing your functions before writing the code (Score:2, Insightful)
Re:Document your code (Score:3, Insightful)
Readable code is great. Don't use it as an excuse not to comment though. It might be perfectly obvious to you what's happening, but that doesn't mean it's obvious to someone else, and you could easily be pissing someone off without knowing it.
Re:Go with the flow (Score:3, Insightful)
Draw lots of pictures.
You don't necessarily need to have a flow chart, per se, but they can sometimes be helpful. Other times just an informal scrawling on a whiteboard will suffice.
What I do is this: First, I write pseudocode. I indent it properly. Next, I turn the pseudocode into comments. Finally, under each pseudocode-generated comment, I will write the actual code to support it. You might also consider these as a good place to break out a function/method from the main programming logic.
I repeat jd's point, and emphasize it: VERSION CONTROL EVERYTHING .
When you discover a bug (as surely you will), some developers like to take the approach of writing a test to look for the bug, then solving the bug. This prevents the bug from creeping back in in later versions.
I think that's all I've got for the moment.
Re:Go with the flow (Score:3, Insightful)
Mean? Way off-topic but can someone explain to me how cunt is any worse than, for example, dick or ass?
Women get offended more easily.
Do Something Fun (Score:3, Insightful)
Do you like games? Write a simple game. Do you like math? Write a program that models some mathematical principles.
Re:a couple things (Score:3, Insightful)
3) take dijkstra's words to heart: "The competent programmer is fully aware of the strictly limited size of his own skull; therefore he approaches the programming task in full humility, and among other things he avoids clever tricks like the plague." corollary: "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." (kernigan)
Both focus on yourself, it could use a team variation, like: "A truly clever developer will create code so easy to understand that a less than average developer could debug it." Hmm... I actually like that so much, I'll put it in my sig.
Re:Go with the flow (Score:1, Insightful)
Excellent advice in the parent. I'd add:
- Get written approval / agreement on all changes to requirements and schedule.
- Get written confirmation on priorities.
- Build automatic testing with the application; a test infrastructure to validate every function point is required. You'll probably spend 50% of your time on testing. It is really nice to be able to run regression tests after a build and **know** you didn't break anything else.
- Pad your schedule by at least 3x. If you really think it will take 2 weeks to code it, report it as 6 weeks so you can add testing, installs, documentation, version control overhead. We're all optimists - before reality happens.
- If you have a release cycle - learn when to freeze new features so you can beet the date by a week.
- Get an independent QA team.
You won't be able to follow most of these suggestions due to a boss who hasn't a clue about software stability.
I only have 22 years of experience, so I'm probably clueless on this development stuff.
Re:Goto is good (Score:4, Insightful)
I agree that as developers we should strive to write good, self-describing code that doesn't need comments.
Yet I still tend to write a lot of comments.
Well-written code can convey most of the how of what you're doing, but it rarely can convey the why -- and that's important too.
Suppose I look at code someone else (or even myself) wrote two years ago. I see what I think is an error in how the logic applies one of the business rules.
Is it an error?
Or was it right, and the business rule has changed?
Or is it still right, and there's some reason for the way it is that I don't understand?
Did someone in management mandate a change that runs contrary to the last version of the design docs? Was a more obvious solution tried first, but found to fail under testing?
All of these things are useful to know, and as much as I'm in favor of self-describing code, it rarely can communicate them.
A few suggestions (from a 30yr veteran) (Score:3, Insightful)
- Approach the job the right way. The goal is not to solve the problem in whatever way possible, but rather to solve it in the cleanest and most easily maintainable/modifiable way. You're not coding to solve today's problem but rather to create code than can be easiliy maintained and modified for the next 10 years.
- Minimalism / clean design. Most often the best design is the one that results in the least amount of code. If you can redesign or recode to result in less code (without reducing the functionality or maintainability) then that is a good thing. You'll quickly learn to regognize clean design/code from that with unnecessary cruft/complexity.
- Push yourself to tackle projects that are at the edge of your capability. You won't learn much doing stuff that is too easy! If work doesn't offer enough challenges (or even if it does), do stuff that stretches you in your spare time.
- Learn new techniques whenever you can. Programming talent is like sharks - it needs to move to stay alive! Whatever language/domain you are working in, try to identity the state of the art tools that others are using, and use them yourself. If you are using C++, learn to use the STL right away (hardly cutting edge, but you'd be surprised how many don't use it).
- Ask questions from more experienced developers whenever they arise, or whenever you suspect there's an easier/better way do to something. You'll advance faster by leveraging the experience of others than by having to repeat all their learning errors yourself!
Re:Listen to the customer (Score:3, Insightful)
>> The technical part is easy
Not true. to hack some crappy code together is easy. To do an excellent job isn't.
Re:Goto is good (Score:3, Insightful)
Yes, and I wanted to break out of *BOTH* loops, not just the inner.
Corporate Dev (Score:3, Insightful)
In general,
like all corporate jobs do as your managers tell you. It matters not if you are wrong or right, it matters not if they are wrong or right, it matters not if you are both wrong, it matters not if you are both right. It matters that they directly control how much you earn and how happy you will be in your role and there is not a damn thing you can do except resign to change things.
Do not publicly dis-agree with your management
Try and make your managers look good
Understand the business you are working in, not just the tech e.g. what is AP/AR/GL
Whatever language you are told to use is OK they all do pretty much the same things using different words. Learn concepts not implementations.
Make efforts to meet your users they are your clients and be respectful to them
The only book you need to pick up is from the pragmatic programmers 'The Pragmatic Programmer: From Journeyman to Master' remember although this book details how to do software dev your management overrides this unless you can convince them otherwise.
There are many other books to pick up but in general pick up classic books not how-tos e.g. pick up Mythical Man Month not Dummies guide to HTML, pick up OOA/OOD/OOP rather than the latest O'Reilly, pick up HTDP/SICP rather than Javascript in 24hrs.
If you wish to transcend the mediocre be prepared to understand that most dev shops are truly mediocre. The current status quo in development is in reality piss poor performance.