Forgot your password?
Programming IT Technology

What To Do Right As a New Programmer? 662

Posted by timothy
from the give-your-coworkers-good-nerf-guns dept.
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."
This discussion has been archived. No new comments can be posted.

What To Do Right As a New Programmer?

Comments Filter:
  • Go with the flow (Score:5, Insightful)

    by Anrego (830717) * on Thursday September 25, 2008 @09:39PM (#25160397)

    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.

    • by tekiegreg (674773) *
      Oh certainly you're not going to forget the book "Code Complete" are you? Then again, what books to read as programmers can be a whole other post,in fact I think it's come up.
      • by Anonymous Coward on Thursday September 25, 2008 @10:19PM (#25160717)
        Tip: Get together with your coworkers after work -- hit a bar on Thursday/Friday night, loosen up, relax, talk shit about your managers, etc. Find out what people do outside of work. Ask the girls if they shave their pussy, the guys if they shave their balls. If you're in the bathroom taking a piss together, compliment them on their cock. Little things like that make the work environment easier and the coding more fun.
      • by digitig (1056110) on Friday September 26, 2008 @05:43AM (#25163437)

        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!

    • by martinw89 (1229324) on Thursday September 25, 2008 @09:46PM (#25160487)

      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:Go with the flow (Score:5, Informative)

        by jd (1658) <.imipak. .at.> on Thursday September 25, 2008 @11:01PM (#25161057) Homepage Journal
        On the other hand, there are some universal rules:
        • Plan/Design everything
        • Document everything
        • Version control everything
        • Test everything
        • Deny everything
        • by Whiteox (919863) <> on Thursday September 25, 2008 @11:34PM (#25161325) Journal

          On the other hand, there are some universal rules:

                  * Plan/Design everything
                  * Document everything
                  * Version control everything
                  * Test everything
                  * Deny everything

          Don't forget:
                  * Lots of GOTOs
                  * Delete those annoying REM statements
                  * Use weird, arcane variable names like 'ORGO' and 'FTOOMSH'

          Good Luck!

          • by Rei (128717)

            Even better than GOTO -- if your programming language supports them, COMEFROM [] statements can be a godsend. If your language doesn't support them, have your program call programs written in languages that do; wise usage of INTERCAL [] linkages can help ensure that you're seen as irreplaceable in your position.

          • by Anonymous Coward on Friday September 26, 2008 @01:24AM (#25162055)

            For the complete list see how to write unmaintainable code at:


        • by Nefarious Wheel (628136) on Friday September 26, 2008 @01:26AM (#25162067) Journal
          Remember at all times that "Listening" isn't the same as "waiting for your chance to speak". You'll get better mileage by laughing at the customer's jokes than telling your own.

          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).

          • Wouldn't have been the Millennium would it? :-)
          • Re: (Score:3, Insightful)

            by John_Sauter (595980)

            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).

            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.

        • Re: (Score:3, Funny)

          by kaizokuace (1082079)
          also, don't boink the boss's daughter for at least 3 weeks!
        • Re:Go with the flow (Score:4, Informative)

          by TrueJim (107565) on Friday September 26, 2008 @07:50AM (#25164047) Homepage

          Whenever you write code on future projects, you're often going to start by trying to re-use code from previous projects. So don't just treat the source-code you're writing now as something you know you're going to reuse in the future. Try to think of each useful chunk of code you write as being part of a "package" that includes not only the code itself, but also the associated documentation, the test cases, the performance metrics, use cases, the build files, etc.

          You want to write the entire -package- so that it can be re-used on future projects, not just the code itself. Remember that as a developer only a fraction of your time is actually spent writing code: the bulk of your time is spent putting together all that associated "stuff." So make the "stuff" re-usable too.

        • Re: (Score:3, Insightful)

          by Phreakiture (547094)

          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 j

    • by SQLGuru (980662) on Thursday September 25, 2008 @10:48PM (#25160941) Journal

      Great stuff. Find a mentor. Most technical classes focus on how to use the language, never how to use it 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.


    • Re: (Score:3, Interesting)

      by jacquesm (154384)

      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 programm

  • by corsec67 (627446) on Thursday September 25, 2008 @09:43PM (#25160431) Homepage Journal

    Along with the ? : ternary opp.

    Code that is hard to read means job security.

    The IOCCC [] is a good place to learn style.

    Sql Injection is a good thing. You don't need to escape user data before send it to the DB, users never do anything bad.

    (Go ahead and mod me troll, I can take the hit. Note that this is actually a list of things NOT to do. Except goto is sometimes useful, for breaking out of a few layers of loops/blocks.)

    • Re:Goto is good (Score:5, Insightful)

      by bigstrat2003 (1058574) * on Thursday September 25, 2008 @09:52PM (#25160525)
      Hey, I like the ? : construct. You leave it alone!!!
    • Re:Goto is good (Score:5, Insightful)

      by liquidpele (663430) on Thursday September 25, 2008 @09:59PM (#25160571) Journal
      I know you're kidding, but I want to make one point. *any* code is unmanageable if you don't comment - especially java if you use lots of objects and polymorphism. Please please please, leave comments so others can figure out what the fuck your logic was without diagramming logic on a whiteboard for 3 days...
      • The only time I liked ? : was in school. It made my source look elite.

        Of course, it didn't matter very much since half of the class didn't turn in working source code anyway, and couldn't figure out how to use scp or ssh, and coded their homework on windows before compiling in the lab with g++.

        I consider it the school's fault that no one knew how to use even basic linux/unix commands, since for the first undergrad C++ class they used textpad + MiniGW port of g++ to code and compile.
      • Re: (Score:3, Insightful)

        by mudetroit (855132)

        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 ar

        • Re:Goto is good (Score:5, Insightful)

          by Rei (128717) on Friday September 26, 2008 @12:14AM (#25161661) Homepage

          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:Goto is good (Score:5, Interesting)

            by Almahtar (991773) on Friday September 26, 2008 @02:52AM (#25162547) Journal
            I'm pretty much in agreement. The compiler can't check your comments: It's explicitly told to ignore them.

            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.


            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()
            does this, that, and another thing.
            ... big long description of inputs, outputs, constants that affect it, whatever ...
            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:Goto is good (Score:4, Insightful)

            by Mongoose Disciple (722373) on Friday September 26, 2008 @11:04AM (#25166331)

            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.

      • Re:Goto is good (Score:4, Insightful)

        by dubl-u (51156) * <2523987012.pota@to> on Friday September 26, 2008 @01:17AM (#25162027)

        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: (Score:3, Insightful)

        by enjo13 (444114)


        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

    • Re:Goto is good (Score:4, Insightful)

      by Rinisari (521266) * on Thursday September 25, 2008 @10:01PM (#25160595) Homepage Journal

      ?: 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).

      • by TheSpoom (715771) *

        I generally only use ternary when I'm outputting or concatenating something and it's a very simple test... otherwise, it's effectively an if (as in the example you posted), and can be more clearly expressed as such. Humans generally think "if x, than y, else z", not "var = (if x, than y, else z)".

        • The main difference between the ternary ?: operator and an if block is that one creates a condition expression while the other creates a conditional statement. There are significant advantages to each in a typical programming language that provides both, but they are certainly not equivalent.

    • by TheRealMindChild (743925) on Thursday September 25, 2008 @10:13PM (#25160685) Homepage Journal []

      Moral of the story: Even when you think a goto is OK, you will still get eaten by a dinosaur.
    • goto is sometimes useful, for breaking out of a few layers of loops/blocks.

      Maybe, if you are still programming in FORTRAN-77. For modern languages, the use of exceptions is recommended.

      • Not so fast. There are exceptions to the use of exceptions.

        It depends on what you're programming for. While this discussion seems to be BigCorp app-centric, there are other coding situations where exceptions are not available. Like, say, anything in a .DLL or .so that might be called by something other than C++.

        Or when writing for next-gen game systems, where your code is running on three different architectures and the tech lead tells you that exceptions are going to be disabled for one of 'em.

      • Re:Exceptions! (Score:4, Insightful)

        by nog_lorp (896553) * on Thursday September 25, 2008 @11:19PM (#25161177)

        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.

  • by Mad Merlin (837387) on Thursday September 25, 2008 @09:43PM (#25160439) Homepage

    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.

    • by corsec67 (627446) on Thursday September 25, 2008 @09:48PM (#25160503) Homepage Journal

      Yep, nothing worse than saying "Who the hell wrote this crap?", running svn blame, and then realizing that I did.

      And, if you aren't using a versioning system, like SVN(preferably), CVS, git, that is a very bad thing. SVN and CVS also have the benefit of getting code to a remote computer when you check it in.

    • by try_anything (880404) on Friday September 26, 2008 @12:36AM (#25161793)

      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!

  • Get out now (Score:5, Funny)

    by Anonymous Coward on Thursday September 25, 2008 @09:43PM (#25160441)

    Get out, now, for the love of God, while you still can.

  • Document your code (Score:5, Informative)

    by TheSpoom (715771) * <slashdot&uberm00,net> on Thursday September 25, 2008 @09:44PM (#25160451) Homepage Journal

    Tab out everything in a code block. This should be obvious, but you'd be surprised how bad some stuff is out there. And try not to put in too many one-line ifs without brackets delimiting the code block... you can easily make the mistake of thinking something should be in the if's scope but isn't becuase there are no delimiters.

    Comment. Comments are incredibly, incredibly important. They kinda go along with an overarching "don't be a douche" rule; while you may know what's going on in your own code, if it's at all complicated, tell the reader what it's doing. If you don't, someone is going to be very pissed at you later. If you want to go above and beyond, do Javadoc [] (or other style appropriate to your language) comments where appropriate; a lot of IDEs actually hook into them so you can highlight a method and see what it's doing.

    And try looking at / working on some open source stuff as well. The big apps usually have a coding style they follow throughout and aren't that bad for a reference.

    • Comments are incredibly, incredibly important. They kinda go along with an overarching "don't be a douche" rule; while you may know what's going on in your own code, if it's at all complicated, tell the reader what it's doing.

      Better, don't repeat what it's doing (by definition, the code itself tells the reader that, and does so without any risk of becoming out of date) but add comments describing why it is doing it.

  • by debrain (29228) on Thursday September 25, 2008 @09:44PM (#25160455) Journal

    ... []

  • Er (Score:2, Funny)

    by Anonymous Coward

    Sometimes I wonder if the editors eyer bother checking the firehose tags for "tvpo" or "tvpoinsummarv".

  • by Anonymous Coward on Thursday September 25, 2008 @09:53PM (#25160535)

    Eat healthy and exercise. Pack your lunch or buy real food instead of the overpriced over-caffeinated junk in the vending machine. You'll save money and feel better.

  • by BrynM (217883) * on Thursday September 25, 2008 @09:56PM (#25160557) Homepage Journal
    Don't stick to just one language (the one they expect you to use). Learn how to do some basic things in several languages. This will help you understand "programming" rather than just knowing a language. Many of the same semantics apply in many languages with only the exact syntax changing. Learn the concepts not the implementations. This doesn't mean that you should try to code in many languages for your job, but as you are presented with problems do a general "how to do x" web search before you do a "how to do x using y language". The best coders I know see a particular language as a tool rather than a mandate. If you only stick to one language, you are imposing an artificial limit to your thought process and ability to problem solve.
    • by corsec67 (627446)

      Also, try to vary the kinds of languages you experiment in, like compiled, or interpreted and functional, or imperative.

      (These are all imperative)
      Compiled: Java, C/C++
      Interpeted: ruby, perl

      Functional []: lisp, scheme, Erlang

    • Your advice equates to "Broaden your background", so I support that thoroughly.

      The most depressing thing about this whole thread for me is that nobody else (yet) has brought up computer science or software engineering. By implication, they're not relevant to a career in programming, and that's a disastrous indictment of the nature of this occupation currently.

      The person in TFA will be getting some training in programming, probably focussed on gaining proficiency in one specific language, but will have no t

      • Re: (Score:3, Informative)

        by TheSpoom (715771) *

        I was going to say, I was a bit surprised that they were promoting someone who presumeably wasn't in coding before into a development position, but the OP isn't quite clear on exactly what background he has.

        While I agree that an education is important (enough that I am further pursuing mine), I also know that he could become a good hacker without it as well. Many people have done so, and have learned the foundation aspects through experience (and the community telling them so).

        I'm still mostly working on P

  • by truthsearch (249536) on Thursday September 25, 2008 @09:58PM (#25160563) Homepage Journal

    - 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 []. 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.

  • by radarsat1 (786772) on Thursday September 25, 2008 @09:58PM (#25160569) Homepage

    Don't read Slashdot at work. :)

  • Ensuring that the business people and cost estimators are aware of hours you believes are required to complete can ensure that you're always in the work in a resource-constrained organization.

    If you give the suits crap, you may put your project at risk of not being able to justify its existence.

  • Read Risks Digest (Score:5, Interesting)

    by Jah-Wren Ryel (80510) on Thursday September 25, 2008 @10:02PM (#25160601)

    Read The Risks Digest [] -- 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.

  • by TheRealMindChild (743925) on Thursday September 25, 2008 @10:10PM (#25160655) Homepage Journal
    1) Your employer will never give you sufficient time to finish what you need to do. Bend over and take it. It comes with the job
    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.
    • Re: (Score:3, Insightful)

      by mudetroit (855132)
      Or you could try working somewhere crazy where they actual value you and:

      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

  • A few tips (Score:5, Interesting)

    by mr_mischief (456295) on Thursday September 25, 2008 @10:12PM (#25160677) Journal

    I'm far from a master programmer myself, but this much I know.

    • Don't get attached to your code. Your code sucks as a newbie. Your code will suck a little less with experience. Even the master coders sometimes write a section of code that sucks. Much of the difference between a newbie and a master coder is that the master coder recognizes his own mistakes when he comes back to them and rips his old code apart to be replaced by new code. The quality of the application as a whole is where to take pride if you're going to be proud of something. Being overly proud of a line, a function, a class, or a library will often get in the way of the quality of the application. Your users don't care about the code you write or how clever/inspired/tight/beautiful/special it is. If rewriting part of the code improves the application, then that's what matters.
    • Bugs happen. Fix them without blaming or arguing. Don't place blame on the people who wrote them. If blame must be placed, place it only on the code in which they were found. Your job is to make the code work, not to piss people off by pointing fingers. You'll write bugs into code, too, anyway, and you don't want every one of them thrown back in your face.
    • Make a habit of promising less and delivering more. It's much better than the other way around.
    • If you're doubting how to design or code a section of a program, ask two people whose programming styles differ. Take as much of the advice of both as will fit into one solution. Try to change which two people you ask from one task to another, even if some of them are not the absolute best programmers on the team. You'll learn more this way than attaching yourself to one mentor unless your mentor happens to be a world-class wizard. You'll also keep allegations of cronyism and team splitting down.
    • Use source control of some sort. Even if your team doesn't use it overall, use it for your portions. Even if it's something really basic like tarring up your project directory at the end of every work day and keeping the tar files, do it. Try to subtly hint at its benefits for the whole group if they're not already using it.
    • Learn a programming language completely different from what you use at work in your spare time. The perspective it gives you can be very helpful. Lisp, Scheme, Haskell, Erlang, and Forth are good candidates for most people to pick up. If you're not exposed to one of Python, Perl, or Ruby at work, pick one and study it at home, too. Any one of those will do, although my personal preference is Perl (after all, it's just a personal preference). JavaScript's object model is interesting, so that wouldn't be a bad choice either.
    • Don't read /. and other sites too much when you need to be coding. It's great to take a break and come back to a problem, but don't overdo the break part when a deadline looms. Cramming and hurrying when coding isn't as easy as hurrying up many other kinds of work.
    • Get plenty of sleep and drink plenty of fluids. I know it's old advice and it sounds corny. All those tales of lone hackers coding all week on coffee, Jolt cola, cold pizza, pot stickers, and hot and sour soup are romantic and inspiring. They're stories about great people getting stuff done against the odds, though. You need to think clearly to code well. If you can think clearly on 3 hours sleep and cold pizza night after night, then good for you. If not, take care of your body so you can concentrate.
    • Set reasonable short-term goals on projects and cross them off one after the other. You don't have to knock the whole project out as one commit two days into the schedule. If you can schedule kind of conservatively and get ahead of schedule, then use that time to improve your code or save it for troubleshooting later in the project. Don't get cocky when one module gets implemented smoothly and tell your boss to shorten the whole schedule. It'll just come back to bite you in the ass if you do.
    • Re: (Score:3, Informative)

      by jschmerge (228731)

      This is all great advice. The parts about not being defensive about code you've written are spot-on. I would add the following to the list:

      • Invest time in making your tool-chain work for you. I've been a professional developer for close to ten years, and tricks that I spent a day figuring out when I was a newbie *still* save me a lot of time. I don't care what environment you're coding in, but having a tool that cross-indexes the source base your working in, and allows you to (in your editor) immediately
  • Columbo (Score:4, Interesting)

    by MarkusQ (450076) on Thursday September 25, 2008 @10:20PM (#25160729) Journal

    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.


  • 10 print "think about doing this\n" 20 GOTO 10
  • by MikeRT (947531) on Thursday September 25, 2008 @10:26PM (#25160787) Homepage

    There are a few advantages to starting with maintenance work:

    1) The majority of the work is probably done for you.
    2) You'll have a chance to force yourself to get used to working with someone else's code.
    3) If you have good senior software engineers working with you, you'll have people who can show you how things ought to be done/have to be done.

    I've been out of college for nearly three years, and most of my experience has been cleaning up the mess that others have made. Usually the projects have been ones written by cheap consultants who got the contract by bleeding themselves dry on their bidding. You'd be amazed at how obviously bad a lot of the work that these do, even though you're just getting out of college.

  • Introduction To Algorithms -- Cormen
    Unix Internals : The New Frontiers -- Uresh Vahalia
    Programming Pearls: John Bentley

  • by madhatter256 (443326) on Thursday September 25, 2008 @10:33PM (#25160847)

    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.

  • by Shazow (263582) <[andrey.petrov] [at] []> on Thursday September 25, 2008 @10:42PM (#25160903) Homepage

    So far I like mr_mischief's reply [] best. Aside from that, here's what keeps me on track:

    • Triangulate. A common mistake I see that produces bad code is people assuming that their code will be used for one thing and one thing always. That is almost never the case, unless you have the time, resources, and naivety to write code from scratch for every project. Try to see beyond the original assignment; set multiple scenarios and applications to your code, and try to fulfill as many of them as you can. Unification is good, and specialization is good--learn when to pick each end of the spectrum.
    • Take pride. It's easy to come up with a 15 if-statement hack, but you'll always save more time in the long run if you spend that extra 15-30 min doing research on how to solve your problem elegantly. If you can't spare the time, do your best to isolate the hacks (such as into their own helper methods) so that you can come back later and replace them with something more sensible. Avoid duplicating code, avoid creating deep chains of method calls, avoid complex undocumented code (if you must write complex code, document what it does so you can keep skimming). In general, try to write beautiful code--something you'd want to paste to your friend, so maybe he can learn a thing or two.
    • Music. When you reach a certain level of confidence that lets you build a flow, try immersing yourself in some good music. For me, listening to The Knife or Justice can significantly enhance my productivity and artistic spirit. Find what works for you.

    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

  • by Repton (60818) on Thursday September 25, 2008 @11:00PM (#25161045) Homepage
    1. Read The Daily WTF []. 2. Don't do that.
  • a couple things (Score:3, Insightful)

    by blackcoot (124938) on Thursday September 25, 2008 @11:57PM (#25161533)

    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: (Score:3, Insightful)

      by Kjella (173770)

      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.

  • Education (Score:3, Insightful)

    by JustNiz (692889) on Friday September 26, 2008 @12:47AM (#25161849)

    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.

  • Some tips (Score:5, Informative)

    by sukotto (122876) on Friday September 26, 2008 @01:08AM (#25161971)

    Here are a few tips off the top of my head.

    * Learn how to use your company's version control system.. and *use* it

    * Comment your code and be smart about it.
    That is... Keep the signal/noise ratio of your commenting as high as possible.
    Comment the big picture and a description of what tricky bits of code are supposed to be doing (and why). Not commenting trivial things.

    * Avoid putting tricky bits in your code :-)

    * Never assume that some code you write is temporary. Lots of mission-critical systems started off as a "temporary" project.

    * Always try to write the best code you can, even if it's just a little one-off (see above point)

    So, that means making sure your function names, variables, etc all have intelligent names. Each block of code does one thing. Each block of code is small (try to keep it on a single printed page, including all whitespace and comments)

    Avoid using global variables, gotos, tightly coupled code, code that messes with the internals of objects/data-structures, etc.

    * Set up a little svn server on your workstation for all those little snippets of test code you write. You never know when you're going to want to go back and look at that stuff again.

    * Read other people's code. Try to figure out if it does what it's supposed to do.

    * Get a good IDE and learn how to use it really well. Use the same one as the majority of your dev team (unless it really sucks).

    * Make yourself as FAST as possible. If you're really fast/efficient then you have more time to think and solve problems:
    - Learn how to type. seriously. get a typing tutor program and do 30 minutes a day until you can touch type as fast as you can speak.

    - Learn the hot-key combos for your programming environment. You won't believe how much faster you'll be.

    - Stop using your mouse for common tasks.

    - Use code templates everywhere you can get away with it. Every time you start a new file, every time you write a new function

    - Learn the idioms of whatever language they have you using. You should never have to stop and think about common constructs in your code

    * Keep a spellbook. If you learn anything cool, interesting, or elegant. WRITE IT DOWN. By HAND I know it sounds stupid, but it really helps

    * Learn how to accurately estimate your time. For everything you're asked to do. Write down how long you think it will take (in hours). At the end of the task, or the end of the workday, track how much time you've currently put in, and how much more you think you'll need. (Never modify your original estimate). Then, when people start asking you to estimate how long a project will take you'll have some historical data to help you come up with a realistic number.

    Pro tip... when you're starting out. Multiply all your estimates by 3. Newbies are usually way too optimistic

    * Read. lots
    Read books on the language your company expects you to learn. Try to also read general books on programming, design, project management, etc. Try to understand the big picture of your project as well as the nitty-gritty of the part you're working on.

    Some good books to get you started
    - Code Complete
    - Pragmatic Programmer: from journeyman to Master
    - Programming Pearls
    - Joel on Software book
    - Mythical man month
    - Getting Things Done

    * At the end of each project, keep a log of what the project was called, what it was for, who it was for, and what you did to contribute. You can also jot down what language you used, what gotchas sprung on you, your estimate accuracy ratio, etc.

  • Left-corner design (Score:4, Interesting)

    by steveha (103154) on Friday September 26, 2008 @02:17AM (#25162393) Homepage

    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.


  • by jthill (303417) on Friday September 26, 2008 @02:30AM (#25162451)

    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.

  • Code to read (Score:4, Informative)

    by univgeek (442857) on Friday September 26, 2008 @08:01AM (#25164105)

    Your code is probably going to be read a bazillion times more than edited. So take some more time to write it clearly.

    Performance is hardly an issue for most business apps - and you should solve most performance issues by choosing the correct algo/method, rather than optimizing code. 80/20 rules applies, 80% of the time is spent in 20% of the code. And the performance critical parts of the code are probably 5% (for most people).

    The compiler is not buggy. Even though gcc might spit insane amounts of errors for a single mistake in STL, the compiler is not buggy. Even though you read your code a hundred times and you can't find a mistake, the compiler is not buggy. It's infinitely more likely that you have screwed up than it is to have a tool error (unless you're doing Verilog/VHDL :)

    Learn to use a debugger. Any debugger will make you appreciate what the code does better.

    Read Code Complete, Pragmatic Programmer.

    10 Learn how to learn better.
    20 Keep learning and practicing.
    30 Goto 10

  • by GNUPublicLicense (1242094) on Friday September 26, 2008 @08:15AM (#25164211)
    Learn C (need to understand the computer memory model), and that's it. All the rest is bullsh... and fashionable stuff.
  • by Zarf (5735) on Friday September 26, 2008 @09:20AM (#25164791) Journal

    ... I'm still a new programmer. Stay adaptable, keep learning, never assume you know all you need to know. Learn from everyone including the new programmers who are just learning themselves. Take time at least once every few weeks to stop and ask:

    • Could I have done that better?
    • How would another developer have done this?
    • How would a programmer on a different platform have done this?

    Once a year I stop and spend some time thinking hard about:

    • How would I have worked the last few year's projects with today's technology?
    • How will things change this year because of what happened last year?
    • How can I position myself and my company to deal with the next year?
    • What should I learn this year and when should I learn it by?
    • What conferences should I attend?
    • How will all this affect my employment prospects?

    So far this strategy has worked for me... of course it took most of the first decade to discover it. You are welcome to copy off of my notes. Asking Slashdot shows you are at least curious, that's good, take time to learn about and learn from leaders in your technology niche.

  • by CFD339 (795926) <andrewp.thenorth@com> on Friday September 26, 2008 @09:41AM (#25165067) Homepage Journal

    Taking the question seriously for a minute -- something unusual for this venue --

    Whatever rules you use, make sure they are the same as everyone else on the project. That includes the rules around comments, indenting, and bracket locations. I've seen huge arguments over placement of an enclosing bracket on the same line as a declaration or a new line.

    Once you have a little comfort in a language, get on an open source team. They have to be very good about practices because they have hundreds of people working in different locations at different time zones around the world. You'll start with no real authority, being allowed to submit small changes specific to small branches of code. The owner of that small branch will be responsible for accepting your changes if they're good enough. Over time, you'll move up the chain. READ THEIR GUIDELINES. OSS teams have, of necessity, very rigid guidelines on code practices that allow hundreds of people to work on code together. They've had huge battles over those guidelines, and very smart people have said very smart things (you can find them hidden in the morass of garbage if you look hard enough) that have gone into those guidelines.

    More Specifically:

    If you're repeating the same code, put it in a sub or function (a method if you're using an object oriented language)

    A subroutine or function should be as fine grained and generalized as you can possibly make it. It should accept as few parameters as it needs, and should return a single value (or perform a single action). Note: Some languages, like C, use the convention of returning a success/failure boolean as the return value, and the result of the function in a buffer passed as a parameter -- that's also a good strategy.

    If your routine is longer than a single screen to read, give real thought to how you might break it out into distinct subroutines (or methods or functions)

    Avoid overly complex rules for variable naming. I've seen insanely complex variable name rules that are painful to work with and attempt to encapsulate the the data type, scope, and purpose of each variable in its name. That's not necessary or helpful in modern language programming. Most programming environments let you mouse click a variable and instantly view its declaration and often even comments written by that declaration for explanation. If your variable name includes the type and scope, you'll have to refactor it if you change the type or scope (like from integer to long integer, or boolean to enumeration as is quite frequent)

    Use an object oriented language where possible

    REALLY learn how to use Overloading, Polymorphism, and inheritance in your object oriented language

    Avoid global declarations and functions wherever possible. The smaller the scope of any variable or object, the less likely someone or something will step on it later.

    draw out -- on paper -- your object model before you build it. Learn to start with an ER (Entity Relationship) diagram so you can understand the relationships between real world objects. Think in terms of "A" is always the parent of one or more instances of "B", "C", or "D", but may be either a parent or a child of "E". Figure that out using real world objects that your code object represents first, on paper. I personally do this on a whiteboard with colored pens first then transfer to software for mapping.

    Trust nothing. Your methods, functions, and subroutines should stand on their own regardless of what crap someone else passes to them. In every method, sub, or function, VALIDATE all variable data, always. Check for overflows. Check to see if an object is instantiated (not null or nothing). Check to make sure values are within the expected ranges. These checks are very small in terms of system resources and program run time. Take the time.

    Do your declarations, validity checking, and decision making outside your loops. Any loop you make should do as little as possible inside it. Everything you do in a loop ge

  • Do Something Fun (Score:3, Insightful)

    by handy_vandal (606174) on Friday September 26, 2008 @09:43AM (#25165101) Homepage Journal
    Do some programming for fun. Invent a side project for yourself, something you want to do for its own sake. Have fun. Play.

    Do you like games? Write a simple game. Do you like math? Write a program that models some mathematical principles.
  • by SpinyNorman (33776) on Friday September 26, 2008 @11:07AM (#25166371)

    - 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!

  • Corporate Dev (Score:3, Insightful)

    by Usquebaugh (230216) on Friday September 26, 2008 @12:54PM (#25167947)

    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.

The clearest way into the Universe is through a forest wilderness. -- John Muir