Tip to become a successful software engineer.

This post is a follow up to Derick’s great post. I could not agree with his view point any more., but it struck a chord with me.  There is more to it. To actually call yourself a software engineer you need to take into account a few aspects of what an engineer should do.


You’re Not Paid To Type

Typing code into a code editor or text editor is not what a Software Engineer is paid to do.  At least, it is not the primary reason this profession exists.  Yes, part of the job is to write code in any number of languages and platforms. As Derick pointed out, it is more then writing code, it is about writing tests, and making sure the code you do type works as designed and can be easily maintained.

All that being said, the actual act of typing is simple and quick.  There is training in keyboard typing and methods to increase how many words per minute one can type. So, does typing more code constructs per minute mean you should to get paid more money?  If you turn out more code then the engineer sitting next to you, have you created more value?  See where I am going with this.  Typing is easy, and typing the wrong code is really easy.  I have seen organizations that are fearful of missing deadlines and dates. Its so unhealthy that the developers think they need to start writing code NOW, but they don’t really know what they are supposed to be creating. They do know what to create in the general sense, but they rush into writing software without knowing most of the details.


You are paid to THINK, so start doing that

So, my main point of this post is that Software Engineers are paid to Think.  You are paid to think about what is the correct code to create, how is should be constructed to lower the total cost of ownership.

If you only change one thing about the way you work this year try this.

  If you normally get your requirements verbally, trying writing them down.

Write down your requirements or technical plan in the easiest manner possible. That could be on a whiteboard, you could annotate a screenshot of an existing screen, you could use pencil and draw the changes to a print out of a screen shot.  Just do something in terms of thinking about what needs to be done before you start typing.  If you do write down what you plan to do, you can actually communicate it to other developers. You can have someone else review it and think through the problem.  You can also show it to the person who will decide if you created the correct software, imagine getting some feedback on what you want to build before you mess it up?

The two most valuable ways I have found to write down what needs to be created are Screen Mockups and Sequence Diagrams. Now, I have been in the web space for a long time, so if you are not creating websites, or web applications, you may find that there are better ways to write down what you need for your particular design problem.  Either way , try to write it down. If you are writing mockups today, then add a sequence diagram for the more complicated problems and see if it helps.  I know it helps me and the developers I work with.

About Eric Hexter

I am the CTO for QuarterSpot. I (co)Founded MvcContrib, Should, Solution Factory, and Pstrami open source projects. I have co-authored MVC 2 in Action, MVC3 in Action, and MVC 4 in Action. I co-founded online events like mvcConf, aspConf, and Community for MVC. I am also a Microsoft MVP in ASP.Net.
This entry was posted in Design, Engineering, Protip, Software Engineering. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • Eeeee


  • Mike Hale

    I worked for a guy who said it productivity was a “a typing issue”. Another manager told me if he caught me leaning back in my chair and staring at the ceiling again he’d fire me. Both places went out of business!

    • erichexter

      It is so sad, but so true.

      • Susheela Simhadri

        but still i didnt get solution for the the thing asked by Wayne Molina

    • Wow.  Yeah a lot of people don’t seem to have any clue whatsoever what is involved in software development.  They think that “If you aren’t typing, you aren’t working” which is so laughable ridiculous it’s not funny.

  • Chris B

    Very well said! On the frustrating side of things, I worked for a large real estate company for a while, and I put a considerable amount of effort into writing down requirements, doing screen mock ups, and doing my best to communicate my understanding of requirements to users *before* writing code. The unfortunate part was that I could not figure out how to get the users to engage in the process. I would show them my mock up and paraphrase requirements and ask them to confirm my understanding was correct, but all I could ever get from the user group was “Yeah, that looks good.” Of course, as soon as something went to production (after they did a very minimal “UAT” process), they would actually review the results and that is when issues and errors would come up.  Since I was completely inexperienced in the industry, I needed significantly more support than I was receiving from the userbase to understand the requirements, and more importantly, related corner cases.

    My only point is really that even if you are doing the right things, like those you suggest here, they are not a silver bullet. If you are writing software for an internal business group, having an engaged group is absolutely critical as well.

  • johnvpetersen

    Nice post. In fact, we are paid to solve problems, with scare resources and still deliver value. That is the essense of engineering. It’s why the “How” aspect of what we do is so important.

    • Priya

      Sir can u plzzzzzzzz suggest me what should I do ?
      I’m Priya 11th sci student i want to become a software engineer…what should I do after my 12th board exams ? Plzz help me

  • Fully agree, I’ll just add one thing- Steve McConnell’s Code Complete was brilliant in using (introducing?) the building metaphor to describe successful programming but people tend to overemphasize that building, while mostly construction, also involves a lot of renovating and even wrecking/destruction.

    Yes, a good software engineer will think before coding but a great software engineer will think about where to add code and also where to *remove* code, or even just add a few strategic comments that clarify a frequently-misread block.

    • Eric Hexter

      That is a great point. A great way to improve the maintainability of software is to know when to delete code, rather then feeling like so much is invested that you need to hang on to code that is not engineered correctly.

  • NQ

    I wish i had found this article earlier. Although i came to the same conclusion.

    Writing stuff is not only better for you to remember, but you will have at least something to rebate.

    It happens (and quite often) where I work, where requirements are transmited verbally, and then once you fulfill them, they are not what the client wanted. In turn, the client then says they need something quite different, and that they asked that the first time.

    Without anything written, and with the premise that the client is always right, the developer is yet again fudged.

    Also, you have a little typo: 
    End of 3rd paragraph: “They do know what to create in the general sense, but they rush intp writing software without knowing most of the details.”

    Guess you did rush “intp” a little writing too  :p

  • Bob

    Guess they don’t pay you to spell check either.  Search for “intp”

    Sorry to sound like a troll, I am not.  I agree completely. 

    As they say thinking is hard, so that is why so few do it.  I’d add thinking is also potentially disruptive so a lot of organizations frown on it.

    • erichexter

      Thanks for pointing that out.. I updated the post. Yeah no one pays me to blog :) .

      My experiences with a number of organizations is that they want their developers to think and be productive. In many cases leadership lacks the experience or insight into what actually makes developers more productive.
      Eric Hexter

      blog | http://Hex.LosTechies.com
      info | http://www.linkedin.com/in/erichexter

      • The fact that leadership lacks experience or insight very rarely prevents leadership from thinking they always know best, IME. And when their opinions and those of the people they manage become too different, they stop listening.

  • Yes software engineering is all about thinking.  It also about asking questions and getting requirements clarified.  It’s also about having courage especially in the web realm.  For instance if sales or marketing want you to create a “contact us” form that requires a user to fill in 30 data items it’s unlikely anyone will fill out that form.  You need to have the courage to point that out to your stake holders.  

  • Dan Sutton

    Here’s a fun and productive systems design method which I use a lot when I have to sit down and design systems with non-programmers (please don’t use the term “Software Engineer”: it demeans us) which works like this:

    1. Get everyone to write simple sentences about how the system is supposed to work: “The customer buys products”, “The user logs in” and so on. Once you all think have enough sentences to describe your entire system, then this part is done. Be patient.

    2. Get a bunch of little index cards. Take the nouns from all of the sentences and write one on each card. Get the other participants to help: it connects them to the process more viscerally. When you’re done, each index card represents an object class in the object model for your system. Magic words are “is”, which means, “is a subclass of”, and “has” which means “has the following property”.

    3. Get the verbs from your sentences. These are the use cases for the objects. Arrange all the index cards and connect them with lines, writing in your use cases (double-sided scotch tape, a whiteboard and some dry-erase markers are good for this). Watch your colleagues’ faces expand in wonder as the object model surfaces…

    4. Take all your results with a pinch of salt. On no account treat the thing as gospel: it’s at best a guide for development… but at the same time, you’ll be amazed at how accurate it ends up being.

    The nice part about this is that even non-programmers who’ve never written a single line of code can understand this and play a full part in it. Elements of design emerge which would never have been noticed using a standard systems analysis method. The participants feel more connected to the system after it’s developed: they feel as though they’ve been part of a very visceral, intrinsic stage in its creation: indeed, for many of them, the process represents the most creative thing they’ve ever done. I find that they become more helpful during the QA and debugging stages; that their understanding of what’s going on is elevated and that they feel pride in the system once it comes into being.

    • For some reason, your comment reminds me of a nice quote from Henry Ford: “If I had asked people what they want, they would have said faster horses.”

      Your basic assumption is that the solution model and the domain model will mostly be very much alike – you can’t expect non-programmers to build up a model of notions they don’t know about. That’s only the case for a particular type of problems – mostly LOB apps, IME. Even there you usually have at least a small part in each app which has no relation to the domain model, and is strictly implementation specific. This part never emerges naturally if you just try to replicate the domain model.

      My approach is a bit different – but also has limited applicability for non-LOB apps. Get all relevant stakeholders into the same room, and get each of them to describe the operations he wants to perform, in terms of the problem domain. Start building use cases as simple lists of steps, and start the people correlate all use cases, in order to discover discrepancies, gaps and other problems. Iteratively improve the use cases until you get a coherent description of the business process using domain language. This might take a while, and usually cannot be finished in just one long meeting. You may continue the process, once started, via shared documents on google docs, via email, via enterprise-internal collaboration systems, whatever. After this is done, you have what you need to develop the system without much additional input from the end users – you have the essential requirements in a coherent form. What you’ll build may not be the perfect system from the very first version, but since you definitely would have captured the essential aspects of the business process, even if changes will be required, they will be easily implementable – unless some of the involved people had held back on what they actually wanted the system to do, but that’s your job when gathering the requirements, to make sure this doesn’t happen. And your solution design and implementation can go ahead without the need of further involvement of non-programmers, which makes things go faster and leads to a better solution, IME.

      This doesn’t contradict an iterative, agile approach to development, accompanied by frequent deliveries. It’s just a technique to gather requirements efficiently, so that you have all essential information early on. With agile methods or not, IME the most frequent cause of problems or right-out failure of software projects is bad requirements gathering, which cause significant rework later on, so that budget and deadline are significantly overrun. Getting the essential requirements right early on minimizes this risk, and is IMO the most important aspect of an entire project. You may build a sub-optimal application which does the right thing, and still have a happy customer, whereas even if you build a perfect application, your customer will be unhappy if it doesn’t do what it’s supposed to.

      • Yeah – it’s a good way to do it. In practice, if you ride everyone else and really use your brain as a programmer when you’re doing my method, optimizing everything as you go (because end users never know what they really want), then both methods essentially end up being the same: you end up with something very efficient.

        Of course, with my method, you get to be a dictator for a couple of days, and that’s always fun! Once you’re done with it, you can put it into some electronic form, or use a real use-case modeling tool if you happen to like that sort of thing (which I don’t).

        I’ve also seen my method resolve long-standing disputes between various departments, simply because by the end of it they’re all so pumped up and invested in the model that there’s no room for difference of opinion any more!

  • Notredam509

    If you can still remember what your code is for and the ins and outs after 30 years revisiting your work, you are a good software folk.

  • 20yearDev

    Well, said.  We are paid to think and our knowledge is what provides our value to the organizations we work for.  I would add that I consider Visio to be one of the most important tools I use.  If I can’t flowchart the logic of a workflow then I can’t code that logic either.

  • Taofeeklasisi

    I agree with you. The danger in rushing to code is having to throw away much, if not all, of it. I just completed a school management app. When I started, I even thought I had thought enough but I learned that it’s not correct because I didn’t think about the app but about some codes. DB design, DAL, etc. Then WHAM! New features couldn’t be contained in the fragile design. It’s a lesson for life. ‘Good Thinking. Good Product’ – Toyota. Nothing can be ‘truer’ than that.

  • hacker


  • Sudhakar Chaudhary

    Yes, You are right. Many Time When I’m trying to solve a problem it’s take too much time, After that  In Free Time When  Thinking About the Problem , laughing on Me because The Problem is very Simple. But In Case of Experience I think U r Wrong.

    • erichexter

      I am not sure I am following what you disagree with.

  • EdwardHaley

    Being skilled about the several sorts of development tools has aided me do well as a software developer. and this is because of my interest towards software development as it is a wonderful business venture currently

  • Bhindeshi Tara

    ProShark Mobile Application Development

    Just in case you missed some of the
    pertinent facts regarding application development for mobile platforms, here
    are a few that may catch your attention.

    72% of adult Cellphone users text messages

    65% of adult Cellphone users sleep with their phones

    50% of US Cellphones will be smart phones by Christmas

    1 out of 3 Yelp searches is from mobile

    Apple Will Sell $2B in Apps in 2011

    Approximately 40% of social media users access their
    accounts through mobile devices.

    One billion mobile applications were downloaded in the
    week between Christmas Day and New Years Day – Flurry Analytics

    The total global mobile applications market is expected
    to be worth $25 billion by 2015 (up from about $6.8 billion in 2010) –
    Marketsand Markets

    Go to::>> http://proshark.com/

  • Anks
  • Sheo Narayan

    Here is one more article that I found very useful particularly in India perspective – http://www.dotnetfunda.com/articles/show/2792/how-to-become-a-successful-software-professional