digg

Join DiggAbout

Introducing Digg Dialogg!
Check out the first Digg Dialogg with Nancy Pelosi. More guests to be announced soon!

Top ten things ten years of professional software development has taught me

taylor.se — Things no-one told me before I started developing software for money.

Bury
show profanity settings
expand all
  • crosenblum, on 10/12/2007, -3/+9great story, really just good common sense, with lessons experience teaches.
    • disruptor108, on 10/12/2007, -12/+7direct link:
      http://www.designobserver.com/archives/000121.html
    • nipterink, on 10/12/2007, -5/+59that's the list that inspired this list (aka, a different list). just in case everyone else is having trouble getting the page to load (like me). i finally got to it:

      1) Object orientation is much harder than you think
      Maybe it's just me, but coming from Computer Science class I thought that OO was easy. I mean, how hard can it be to create classes that mimic the real world? It turns out that it's pretty hard. Ten years later, I'm still learning how to model properly. I wish I spent more time reading up on OO and design patterns. Good modeling skills are worth a lot to every development team.

      2) The difficult part of software development is communication
      And that's communication with persons, not socket programming. Now and then you do run into a tricky technical problem, but it's not at all that common. Much more common is misunderstandings between you and the project manager, between you and the customer and finally between you and the other developers. Work on your soft skills.

      3) Learn to say no
      When I started working, I was very eager to please. This meant that I had a hard time saying no to things people asked of me. I worked a lot of overtime, and still didn't finish everything that was asked of me. The result was disappointment from their side, and almost burning out on my part. If you never say no, your yes is worth very little. Commit to what you can handle, and if people keep asking you for more, make it very explicit that this would mean not doing something else. What I did was to have a list of stuff that I needed to do on a piece of paper with me. When someone asked for something, I showed them the list and asked what I should bump to have time to help them. This allowed me to say no in a nice way.

      4) If everything is equally important, then nothing is important
      The business likes to say that all the features are as crucial. They are not. Push back and make them commit. It's easier if you don't force them to pick what to do and what not to do. Instead, let them choose what you should do this week. This will let you produce the stuff that brings value first. If all else goes haywire, at least you've done that.

      5) Don't over-think a problem
      I can spend whole days designing things in front of the white board. That doesn't mean it will be any better, it just means it will be more complicated. I don't mean to say you shouldn't design at all, just that the implementation will quickly show me stuff I didn't think of anyway, so why try to make it perfect? Like Dave Farell says: "The devil is in the details, but exorcism is in implementation, not theory."

      6) Dive really deep into something, but don't get hung up
      Chris and I spent a lot of time getting into the real deep parts of SQL Server. It was great fun and I learned a lot from it, but after some time I realized that knowing that much didn't really help me solve the business' problems. An example: I know that at the table level, SQL Server will not take an IU lock - it will only take a IX lock. This is a performance tweak, since most of the time, the IU lock will have to be escalated into a IX lock anyway. To find this, I spent countless days experimenting, I read loads of material and talked to Microsoft people at conferences. Have I ever had any use of this knowledge. Nope.

      7) Learn about the other parts of the software development machine
      It's really important to be a great developer. But to be a great part of the system that produces software, you need to understand what the rest of the system does. How do the QA people work? What does the project manager do? What drives the business analyst? This knowledge will help you connect with the rest of the people, and will grease interactions with them. Ask the people around you for help in learning more. What books are good? Most people will be flattered that you care, and willingly help you out. A little time on this goes a really long way.

      8) Your colleagues are your best teachers
      A year after I started on my first job, we merged with another company. Suddenly I had a lot of much more talented and experienced people around me. I remember distinctly how this made me feel inferior and stupid. I studied hard, reading book after book but I still didn't catch up. They had too much of an advantage on me, I figured.
      Nowadays, working with great people doesn't make me feel bad at all. I just feel I have the chance of a lifetime to learn. I ask questions and I try really hard to understand how my colleagues come to the conclusions they do. This is why I joined ThoughtWorks. See your peers as an asset, not competition.

      9) It all comes down to working software
      No matter how cool your algorithms are, no matter how brilliant your database schema is, no matter how fabulous your whatever is, if it doesn't scratch the clients' itch, it's not worth anything. Focus on delivering working software, and at the same time prepare to continue delivering software using that code base and you're on the right path.

      10) Some people are assholes
      Most of the time, most of the people around you are great. You learn from them, and they learn from you. Accomplishing something together is a good feeling. Unfortunately, you will probably run into the exceptions. People that because of something or other are plain old mean. Demeaning bosses. Lying colleagues. Stupid, ignorant customers. Don't take this too hard. Try to work around them and do what you can to minimize the pain and effort they cause, but don't blame yourself. As long as you stay honest and do your best, you've done your part.
    • CrankyPants, on 10/12/2007, -4/+1@nipterink

      I like your list better. Way more practical.
    • Haplo, on 10/12/2007, -2/+2#11 - if you work fixed price and you notice that it's going to take more time talk with the customer and NOT with yourself (like: yeah, I can use this probably in another project, it's my fault, yada yada). Took me some time to get this, but my customers DO pay the additional time. Of course the earlier you talk the better.
    • nunofgs, on 10/12/2007, -2/+4"What I did was to have a list of stuff that I needed to do on a piece of paper with me. When someone asked for something, I showed them the list and asked what I should bump to have time to help them. This allowed me to say no in a nice way."

      I'm trying to imagine a scenario where I do what you described and not look like an *****. Nope, there isn't one.
      It's like someone is pointing a gun at your parents and going: "Here, you choose!"
    • bysin, on 10/12/2007, -2/+5I'm going to have to disagree with this guy on a number of items. I've been a professional developer for longer then 10 years, and some of his items I take a complete opposite stance with. Its all about personal experience, so I wouldn't use this as a guide or reference, but more of one man's opinion.
    • Strd, on 10/12/2007, -2/+18. It all comes down to working software

      But what if it works, but the code is ugly ? That's the real question.
      To refactor or "If It's Not Broken, Don't Fix It". There is usually no time allocating specifically to refactoring, if you are doing it you are doing it at your own risk.
      You may save time on the later code maintenance or modification, but may be not...
  • Darkhacker, on 10/12/2007, -9/+461. I agree and this is why I rather dislike OOP. My feelings are mixed on it but I personally avoid it unless I see a good reason to use it. It seems to me that people just jump on the bandwagon of OOP without asking themselves WHY it is necessary over procedural programming.

    2. I don't have the source off hand to cite but I've read numerous times that Linus Torvalds actually prefers email because you can communicate more efficiently if things are written out and people have a chance to reply. Hell, just this week I had to go over to someones house so he could give me a CD containing 5 MB of information. I asked him if he wanted to say anything or talk about something and nothing came up. The thought never even occured to him that he could have simply emailed me those files. In the business world though that would waste a lot of time.

    3. I'm currently working on two (three soon) projects and only one of them I am in charge of. I've noticed though that my best work comes through on the one that I am in charge of because it is much easier to say 'no' to completely back-assword ideas.

    4. I've never actually had this problem, even in projects where I was the code-monkey. People seem to understand priorities and in fact will request that I work on certain features before anything else.

    5. I find the best way to avoid this is to make your first design using common sense. Try not to think like a strict programmer but just in very general terms. Then make a list of what you like... AND, most importantly, make a list of what you DON'T like. I find that all too often people avoid the ladder and end up with everything they liked and wanted but just as much crap that they didn't.

    6. Don't fix what isn't broken.

    7. Depends on the project. Being that I am the only programmer on most of my projects I find that I shouldn't and don't care what everyone else does as long as MY work gets done.

    8. I agree, but don't take everything they say for a pot of gold. I remember I spent 4-5 hours debugging the simplest of problems because the guy I looked up to told me to do it that way. This was back in the days when I actually did work with other developers. I really miss those times though. Working alone isn't as much fun.

    9. Most of my work is as a web developer and when I get bitched out occasionally by non-programmers, I've noticed that W3C validation is rather low on their list of 'things I should worry about'.

    10. Most of the people around me are wonderful. What really sucks is when people completely outside your project think they have some say in how it runs. At my high school the website is grouped in with the journalism department because most of our content is stuff from the school paper. This is the one project I've been requested to do that I am actually in charge of, yet people from the other staffs (especially photographers) like to cause trouble. The website is ranked as the lowest staff besides J1 (the introduction to journalism class) because our deadlines are very loose and it isn't a complete crisis if we miss it like it is with Yearbook (highest ranked) that gets fined out the ass by the publishing company if they are even a day late. Because we are ranked so low in terms of priority, people think that gives them the right to treat me on a personal level like complete *****. Despite the fact that we are overall the most useful staff (faster updates, multimedia, lowest publication costs).
    • jasnmb, on 10/12/2007, -37/+2I had to digg your comment down for being too long. I don't want to read a blog in the comments section.
    • thewump, on 10/12/2007, -6/+3Hey man - I'll digg your comment up just on the grounds of the effort you put into it!
    • Philodox, on 10/12/2007, -0/+11To be fair the article says that OOP is hard, not that it shouldn't be done. In many situations writing procedural code is way more messy than OO.
    • stalinvlad, on 10/12/2007, -11/+31. OOPs bandwagon? Structured programming?
      Your taking the piss right?
      Structured programming; Ever seen an unstructured program get thru an edit? Nope?
      OOPS is a paradigm, a method of thought you (and a C++ compiler+linker) can do OOPS in assembler, hell *****, spew it out in HEX baby!

      If I had you two thick as ***** dorks turn up for work... well you know, Id put you in marketing, but not HR.
    • CrimsonBlur, on 10/12/2007, -3/+6@jasnmb
      Then don't read it! If you haven't read the whole comment don't bury it, simple as that. Darkhacker's comment happens to be a good one, is on-topic, and provides additional, meaningful information about the subject. I like Digg's comment system because it makes it very easy to see who is making too many off-topic comments, flaming, etc. The problem is, too many people press the red button for the wrong reasons (like the comment is too long. That's stupid). Luckily people can digg it back up if they catch it soon enough so it usually corrects itself. Well, sometimes it does anyway.

      I agree with Darkhacker wholeheartedly on #2. For business communication email is almost always superior to anything else. Meetings are great for brainstorming sessions and that's about it. Talking over the phone is, honestly, usually a waste of time because: email gives you an opportunity to reflect on the conversation as a whole and make a detailed response without necessarily having to take a great deal of time to do so. It also enables you to have an exact record of the entire conversation, even if it lasts days, weeks, etc., which makes it trivial to point out mistakes or simple misunderstandings without an argument. Communication skills are of course important, but it has more to do with getting along with your coworkers on a personal level than it does actually getting work done; which is why I prefer email unless I actually want to have personal discussion.
    • bart9h, on 10/12/2007, -3/+1@thewump "Hey man - I'll digg your comment up just on the grounds of the effort you put into it!"

      or because, like me, you were lazy to read it all?
    • NoHandle, on 10/12/2007, -1/+10OOP simplifies things. Unless you are a dinosaur, you should be quite familiar with it. If you are familiar with it, you will see why it is useful. I have never heard anyone who understood object orientated programming say that procedural is the way to go. The only people who say this are older software engineers. This is only natural, whatever is familiar is always easier. I respect those who are older than me because they know more than me, but that doesn't mean that they know everything. I have experience with both techniques and there isn't even an argument to be put forth, OO is to programming as C was to assembly.

      This is because at the end of the day, we are all just humans and truly limited in our capabilities. Abstracting problems and solutions to those problems helps us use these previously derived solutions as a building block, rather than a tool to build another block. Because we only need to make sure we are creating generic enough blocks, it becomes a matter of putting them together correctly. This should result in simpler, more abstract code that is quick to read and easy to understand. Save the complication for envisioning what the whole thing does rather than how each piece works.
    • ZergyPoo, on 10/12/2007, -1/+41. There's a right and wrong place for everything.

      OOP can be very helpful if structured properly. However, it can be extremely complicated to structure it properly. For most projects, it's overkill.

      That's not to say that it isn't a great idea. But I know many people who are on different sides of this argument.
    • dlsspy, on 10/12/2007, -0/+3@NoHandle

      Advocating OOP over (what you seem to be implying is the only alternative,) imperative programming isn't any better than people who only know imperative programming advocating it over OOP. What about FP? I tend to get more reuse and simplicity out of my FP programs than I do out of my OOP programs. I have a lot *more* OOP code, but that's probably just because it generally takes more.

      Re: ``OOP is to programming as C is to assembly''

      Where do you place something like Haskell in here? The major OO languages and C both have you doing roughly the same job: telling the computer how to do something. The primary difference between the two is organization (and some fancy stuff like polymorphism that lets you contain the decision making a little better).

      When you're writing FP code, more effort goes into describing *what* to do, and less into how to do it. This allows the compiler to do wonderful optimizations because instead of micromanaging it, ``I would like to declare a new list and begin iterating this list. I have received an element. I would like to create a new value based on this value and mutate my other list to contain my new value [etc...]'' you can say, ``map (x -> x + 1) [1,2,3,4]''

      ``Bah! Syntactic sugar!'' you say...however, I've told it *what* I want done, not *how* to do it. The compiler could decide that on my 80-core intel chip, it can cheaply run each transformation *simultaneously* and then assemble me a new output list in order when they all complete.
    • d03boy, on 10/12/2007, -2/+1Gosh, I can't imagine why you would possibly over look the usefulness of OOP... maybe because you're a web developer? Not surprising seeing the word 'hacker' in your name.
    • grumpyrain, on 10/12/2007, -0/+1> Abstracting problems and solutions to those problems helps us use these previously derived solutions as a building block, rather than a tool to build another block.

      Furthermore, with good class and method names, OO strongly assists in documenting your software. Comments in code are useful for explaining unusual actions taken, but good code is self explanatory even to non-programmers. (That is not to say that you should deliberately search for unreasonable levels of abstraction, if your problem can be solved with 3 lines of code, chances are a simple procedural program is the way to go). OO also helps with security. If you discover a vulnerability in your software, it is much easier to fix if you only have to correct a particular class rather than search for everywhere that and similar code may have been used. OO groups your code together into meaningful objects with purpose. Procedural code is forever tempting you to put logic where it doesn't belong, and no-one wants to maintain a spaghetti code. Inheritance is another powerful feature that can save a lot of time and bugs.
    • dlsspy, on 10/12/2007, -0/+2@Grumpyrain

      OO does *not* help with security. If you are cutting and pasting code, you're likely to do that in any language. Languages like java almost encourage such things (aspectj helps a lot here).
    • ABadInAlbany, on 10/12/2007, -0/+2I'd been a procedural guy for almost 15 years, really only started getting into OOP in the past 3-5 years. Yes, there's a lot of overhead involved. However, it plays a necessary role. At the moment, I'm in the middle of architecting an OOP design that allows abstraction of two different software systems that both handle, or will handle, similar work, as we transition from a legacy VSAM mainframe environment into a newer, RDBMS-driven system that allows greater flexibility and adaptability. This abstraction is critical in order to allow clients of the legacy system to access the newer system with minimal modification. When you have half a dozen or more major clients accessing your backend, you can't do without abstraction -- if everything's procedural, you start to locate far too much of what should be common logic in your clients, duplicating effort and knowledge throughout the system, making it extremely difficult to maintain, to say the least.

      One more aspect of this system, which provides "translations" of shorthand notations and information within the mainframe system into verbose, human-readable (without months of training) "rules," "notices" and "alerts." This system too needs to be transitioned to the new RDBMS system. In a meeting yesterday, our senior systems architect cautioned me to "find the line" where the amount of OO engineering I put into the transition is not overwhelming the value we get out of it. If it can't be purely OO, driven by the RDBMS relationships, then we'll strike a happy medium. OO has its place, but so does sensibility. Everything's a compromise, it's just a matter of what you're able to accept AS the compromise.
    • NoHandle, on 10/12/2007, -0/+2@dlsspy:

      I have experience with Function and Logical programming languages. Perhaps, just as those who are new to OO, I did not enjoy my time with them because they were very unfamiliar. You will have to admit that Functional and Logical programming are completely different when compared to imperative languages, both in how you think about them and solve problems using them. Functional programming tackles problems in a completely different manor than anything we have classically been instructed and that isn't necessarily a good or a bad thing. Sometimes seeing something in new light will help you understand it better. I saw Haskell complicating things more than helping and this wasn't just from my experience with it because I wasn't that experienced with other languages when I started playing with it. It didn't feel natural to me and everything you did felt forced. Admittedly, those with stronger math skills seemed to flourish with it.

      Each language has its uses and for general day to day work, as well as large scale projects, you have to go object orientated. Functional programming is great for math problems, as that is what it is intended for and who has adopted it the most. Lazy evaluation is extremely powerful for this purpose, but not so great when you are not just solving difficult formulas. This is the same as Prolog being great for AI, logical languages are extremely good at this because it simplifies things for the programmer and this is what my message is. We tend to see complexity as an achievement, but the simpler something is, the more complex it can be in the grandeur scheme of things. In a sense, we can handle only so much complexity and if it is removed from programming, then it can be moved up to another level. One day we will solve this complexity with another programming paradigm and I look forward to that day. Though I know it will be difficult to forget everything I learned up to that point, just as some have had to do before me.
    • crosenblum, on 10/12/2007, -0/+2That's a valid concern.

      I really do think we can architect/plan/organize our applications better, I just feel that for most applications, oo is just of no value.

      I don't have an answer or THE answer...my gut keeps telling me this is the wrong approach...

      If it works for you, go ahead and use it. But please don't make me out to be a jerk if i don't support what you support.

      Actually I found this article rather well written, and well thought out.

      I really do want to be a better programmer, just not always some one to ask questions, at times, it feels there are no real support for programmers, especially web-based ones. I know there are user groups, but unless you follow a certain way of doing things, that are trendy, which i don't follow because trendy does not equal correct.

      I guess my few words of wisdom are.

      1. Plan well
      2. long term vs short term always pays off

      If you make more monkey code, when it honestly just needs to be redone, your only making it harder on yourself by not maintaining the code/applications as you work on them.

      Care about the quality of the code on the outside and inside, this is your craft, this is what people look at.
  • Detritus, on 10/12/2007, -11/+3Top #1 things Digg has taught me:

    1) Internets don't need anymore Top 10 lists.

    (First time I've ever buried a Swedish article! Goddag, Sverige! Hålla scen i livet.)
    • stalinvlad, on 10/12/2007, -5/+2How about a BOTTOM 10 list
      10 insubstantial facts no one need ever know
      #1. God is Great, the ***** knobstick
  • thewump, on 10/12/2007, -3/+6I like it.

    On OO my feeling is that if OO is something that a language CAN do ( like PHP ) then it's hard work, but if it's something that a language is BUILT AROUND ( like Ruby.. and therefore Ruby on Rails ) it all comes together quite intuitively.

    If you like this article, you will probably also like the thinking in the 37signals free ebook at http://www.37signals.com
    • Coolwave, on 10/12/2007, -0/+3I was thinking the whole time I read the article that it feels like a summary of the Getting Real Book!!!
      http://gettingreal.37signals.com/

      I still dugg the story anyways, but I have to say about #1 that I learned more about OOP from learning Ruby on Rails than I ever have in school or by programming in any other language. It all makes sense now...
  • wphj, on 10/12/2007, -3/+1http://www.duggmirror.com/
  • rooskie, on 10/12/2007, -9/+5full text:

    # Object orientation is much harder than you think
    Maybe it's just me, but coming from Computer Science class I thought that OO was easy. I mean, how hard can it be to create classes that mimic the real world? It turns out that it's pretty hard. Ten years later, I'm still learning how to model properly. I wish I spent more time reading up on OO and design patterns. Good modeling skills are worth a lot to every development team.
    # The difficult part of software development is communication
    And that's communication with persons, not socket programming. Now and then you do run into a tricky technical problem, but it's not at all that common. Much more common is misunderstandings between you and the project manager, between you and the customer and finally between you and the other developers. Work on your soft skills.
    # Learn to say no
    When I started working, I was very eager to please. This meant that I had a hard time saying no to things people asked of me. I worked a lot of overtime, and still didn't finish everything that was asked of me. The result was disappointment from their side, and almost burning out on my part. If you never say no, your yes is worth very little. Commit to what you can handle, and if people keep asking you for more, make it very explicit that this would mean not doing something else. What I did was to have a list of stuff that I needed to do on a piece of paper with me. When someone asked for something, I showed them the list and asked what I should bump to have time to help them. This allowed me to say no in a nice way.
    # If everything is equally important, then nothing is important
    The business likes to say that all the features are as crucial. They are not. Push back and make them commit. It's easier if you don't force them to pick what to do and what not to do. Instead, let them choose what you should do this week. This will let you produce the stuff that brings value first. If all else goes haywire, at least you've done that.
    # Don't over-think a problem
    I can spend whole days designing things in front of the white board. That doesn't mean it will be any better, it just means it will be more complicated. I don't mean to say you shouldn't design at all, just that the implementation will quickly show me stuff I didn't think of anyway, so why try to make it perfect? Like Dave Farell says: "The devil is in the details, but exorcism is in implementation, not theory."
    # Dive really deep into something, but don't get hung up
    Chris and I spent a lot of time getting into the real deep parts of SQL Server. It was great fun and I learned a lot from it, but after some time I realized that knowing that much didn't really help me solve the business' problems. An example: I know that at the table level, SQL Server will not take an IU lock - it will only take a IX lock. This is a performance tweak, since most of the time, the IU lock will have to be escalated into a IX lock anyway. To find this, I spent countless days experimenting, I read loads of material and talked to Microsoft people at conferences. Have I ever had any use of this knowledge. Nope.
    # Learn about the other parts of the software development machine
    It's really important to be a great developer. But to be a great part of the system that produces software, you need to understand what the rest of the system does. How do the QA people work? What does the project manager do? What drives the business analyst? This knowledge will help you connect with the rest of the people, and will grease interactions with them. Ask the people around you for help in learning more. What books are good? Most people will be flattered that you care, and willingly help you out. A little time on this goes a really long way.
    # Your colleagues are your best teachers
    A year after I started on my first job, we merged with another company. Suddenly I had a lot of much more talented and experienced people around me. I remember distinctly how this made me feel inferior and stupid. I studied hard, reading book after book but I still didn't catch up. They had too much of an advantage on me, I figured.
    Nowadays, working with great people doesn't make me feel bad at all. I just feel I have the chance of a lifetime to learn. I ask questions and I try really hard to understand how my colleagues come to the conclusions they do. This is why I joined ThoughtWorks. See your peers as an asset, not competition.
    # It all comes down to working software
    No matter how cool your algorithms are, no matter how brilliant your database schema is, no matter how fabulous your whatever is, if it doesn't scratch the clients' itch, it's not worth anything. Focus on delivering working software, and at the same time prepare to continue delivering software using that code base and you're on the right path.
    # Some people are assholes
    Most of the time, most of the people around you are great. You learn from them, and they learn from you. Accomplishing something together is a good feeling. Unfortunately, you will probably run into the exceptions. People that because of something or other are plain old mean. Demeaning bosses. Lying colleagues. Stupid, ignorant customers. Don't take this too hard. Try to work around them and do what you can to minimize the pain and effort they cause, but don't blame yourself. As long as you stay honest and do your best, you've done your part.
  • geronimo, on 10/12/2007, -0/+5I learned a bit late that coffee and meditation can dramatically improve productivity. And if you find yourself talking negatively about coworkers then it's time to move on and find / make your own environment. Complaining means you aren't in control and you think you are a victim, you can move on anytime you like. You should never complain. If you have a problem with someone, tell them. And always keep your word. Others will imitate you.
    • vwvwvw, on 10/12/2007, -0/+6I agree 100%. Negativism is a cancer and most of it is self-created. I think this is the single most difficult challenge facing technical people and is something I still struggle with. Sometimes you just have to take a breath and tell yourself "it's just a job", it's not worth stressing out over. I guess we live with the fear of somebody who has power over us thinking that we're worthless failures if we can't meet expectations. Even scarier when our supervisors aren't technical and don't have the understanding to assess our competency. What do they base their opinions on? How do they know we're strong developers? I guess the answer is just to bury our heads in code and keep doing what we do best. Can't worry about what we can't control.
    • nubi78, on 10/12/2007, -0/+6geronimo, Great comment,

      I work with guys who bitch all day. About the job, the work, the company changes, the 401k, health care, the job, work, company changes, 401k, health care... repeat and repeat... then they have lunch. After lunch, they bitch about the job, the work, the company changes, the 401k, health care, the job, work, company changes, 401k, health care... repeat and repeat,

      I tell them that there are other companies, and other jobs inside of the same company, they laugh and say they don't want to leave and then proceed to bitch about the list above.

    • geronimo, on 10/12/2007, -0/+2People like that will always be at that position, complaining and wondering why they remain in that position, not thinking they are the problem. Once you get it, everything will become easier. You find people who also get it, start a company and everything falls in place.
  • antdude, on 10/12/2007, -1/+2http://www.designobserver.com/archives/000121.html
  • vwvwvw, on 10/12/2007, -3/+1I knew a #10 that didn't understand #9, wasted our time with #5.
  • adinb, on 10/12/2007, -0/+1I would add "Focus on your pieces, but envision the pieces as they fit in the overall system." When looking at requirements in your design, the design of the overall system may make a difference--a tweak to the class hierarchy may make everybody's job easier. But sometimes when the echelons of a large project make a decision its because they have a broader understanding of the overall requirements. (Though it may just be a sign of poor Systems Engineering)

    And if the PM/Software Architect/Sys Engineer/Lead Dev can't fully explain or clearly write down the requirements, RUN! (for the hills, aka tune up the ol' resume)
  • hackwrench, on 10/12/2007, -0/+4Your colleagues are your best teachers...See your peers as an asset, not competition.

    To look at it another way, the student-teacher and by generalization, all other superior-subordinate models aren't all they're cracked up to be.
  • friedcalamari, on 10/12/2007, -0/+8What about the Dilbert principle?: "Never promote good programmers otherwise you will end up with nobody to get the job done"
    • vwvwvw, on 10/12/2007, -0/+2True, although the managerial theorem is: "If the system works, don't change it"
  • Urusai, on 10/12/2007, -7/+1Some people are assholes? Not if everybody just did what I tell their stupid asses to do. Unfortunately, horsewhipping people is frowned upon in this society of pussies.
  • gafasiesornivek, on 10/12/2007, -2/+2Not how to build a server obviously.
  • geronimo, on 10/12/2007, -5/+2d'oh. Digg me down to -infinity.
  • tdurden, on 10/12/2007, -9/+210 years and OO is still that difficult for you?
    • d03boy, on 10/12/2007, -0/+6Let me guess, you know the singleton pattern?
    • tdurden, on 10/12/2007, -4/+1@d03boy ... I take it you are having a tough time with OO based on your sarcastic comment....give it a decade or so like this guy and you may get it
    • ABadInAlbany, on 10/12/2007, -0/+2@tdurden: it's not tough to "get" OO. it is tough to implement OO in an effective manner across a broad spectrum of systems and applications. OO is art as much as science, and the set of variables changes with each new system, new set of stakeholders, new set of needs. If you think it's universally simple, you're a simpleton. The concepts of OO? Easy. The application of OO in a fashion that's valuable, without wasting resources or overengineering soemthing that produces sub-par return on investment? Takes effort, no matter how long you've been doing it. I've known some crazy ace OO guys, guys who have been working with OO since the late 70s, when the idea was still taking off, and this is their philosophy as well as mine.
    • tdurden, on 10/12/2007, -0/+0@ABadInAlbany Point taken - Ive been at it for about a decade and should probably look at it from another angle.
  • aznmikex215, on 10/12/2007, -0/+3I am graduating Temple University with a BS in Computer Science. I hope to be a developer soon. I like post like these where I can read and learn from other people's experiences.
    • fuzzynyanko, on 10/12/2007, -0/+1Same here. I'm about to start on a software engineering career and I take advice openly, but only use the pieces of advice I like, and I like almost all of these.
  • aznmikex215, on 10/12/2007, -1/+2oops.
  • zotzed, on 10/12/2007, -2/+2With 14 years in the industry as a developer and project manager, I can agree with all of these.
  • chinared, on 10/12/2007, -1/+0As a fairly experienced commercial music producer, I really have to agree with these rules-of-thumb. A quirky, technicaliche article that can apply to most jobs that require over-thinking! Digged.
  • abjorck9, on 10/12/2007, -0/+01. Communicate! Don't waste time when you get stuck or have questions. Ask for help right away.
    2. Keep it simple stupid. There is no one to impress but yourself.
    3. Conceptual Integrity. Look it up, and remember it always.
    4. When talking to customers, remember that YOU are the professional. You are supposed to have an opinion.
  • _HAM_, on 10/12/2007, -0/+23. Learn to say no

    Probably the best advice on the article. Within the first two months of getting my first software developer gig I nearly quit the whole thing simply because I was too eager to please and nearly bunt myself out.

  • Topher06, on 10/12/2007, -0/+5First, about OOP, if you don't get it, you never will. Those that dislike it don't get it. They make arguments that people lump classes together for no better reason then to lump classes together. I have also seen some pretty horrible examples of OOP. But ultimately because they don't understand or get OOP, it just suck as a programming paradigm.

    But what is the alternative? Non OOP is just a bunch of files that merge code with with similar purposes in some loosely connect way. Most people that are non-OOP tend to do really do informal OOP, they use namespaces and static function and strucs to basically emulate a class, except that the moment you talk about changing their code to a class, their eye's glaze over and they don't want to hear it.

    Someone here said that its hard to program OOP for real life, even after 10 years of experience. WFT? Its easy to program for real life using OOP. A class is an object, link everything to do with that object in the class, and most REAL things are easily defined as an object. A bank transaction, a picture on the screen, a sound file, a database query. I find it very hard to NOT think of the real world as a collection of objects that I can easily describe as a class.

    Sorry, after 10 years of programming experience, I am not only using classes, but I implement virtualization, templates, and creating new objects by knowing how to derive from base classes. OOP allow easy code reuse and modularity. I find that people that don't OOP are forever cutting and pasting functions and code in order to create something similar, but only varies slightly in code. They have 6 segments of code that do all the same thing, but rewritten slightly in each case, if there is a bug in the basic logic of one code section, its hard to find, understand and fix ALL affected code. If there is a bug in the fundamental logic of a base class, fixing it will fix the rest of your code that is derived from it for free. I find non-OO code to be considerably more bug prone, and further, it takes longer to fix bugs because of its archaic and informal organization of logic. Lastely non-OO code requires discipline that I have seen few programmer exhibit. non-OO code tends to become spaghetti logic, not just a collection of confusing goto and function calling, but this logic spreads across multiple files. I remember once debugging non-OO code and I had over 50 files opened that were all involved for ONE operation, stepping through the code just kept calling more and more functions and opening up more and more files. I rewrote the entire 50+ file mess into 5 concise files describing a handful of objects.

    I code for C++ for desktop applications, its almost necessary to do it OOP, I hate looking at or having to code non-OOP. I can see for web development, or in other areas of development OOP is overrated, but if your coding C style for modern applications on the newest OS, you must also like driving with square wheels. Sure you might eventually get there, but its a painful humiliating experience.
    • EvolvedAnt, on 10/12/2007, -0/+2I agree, most problems people have with OOP is simply because they don't understand how to use it or where it is most nessesary. So instead of simply admiting that they don't understand OOP that well, they resort to bashing it instead.

      The problem in my opinion stems from the fact that most OOP books do a terrible job of showing the true advantages that programming in OOP offers compared to procedural. I never understood how great OOP was no matter how many books I read until the day I actualy used it for a computer game I wrote. My personal favorite benifit to OOP in game programming is when I can create a Monster base class with some basic A.I. routines, and then gain the ability to add new monsters to my game like Skeleton class and have it fully functional simply by inheriting from the base Monster class.
  • domesterz, on 10/12/2007, -0/+0OO is not easy to design but it easys to develop after design is finish !
  • sarahmaddelson, on 10/11/2007, -0/+0Thanx a lot for the info. That's true, I confirm.
  •  

    Login or register to add a comment

    Create a new account or login to join in the conversation on Digg. You'll also be able to Digg stories to help promote things you like.


© Digg Inc. 2008 — Content posted by Digg users is dedicated to the public domain.
DIGG, DIGG IT, DUGG, DIGG THIS, Digg graphics, logos, designs, page headers, button icons, scripts, and other service names are the trademarks of Digg Inc.