software engineering

Becoming an Entrepreneur as a Software Engineer Vol 1

This is the first post in what I plan to be a series.  In these posts, I will explore ideas in entrepreneurship.  It’s a given that working for yourself, while it brings many risks, can bring many rewards.  I believe that it is one of the only ways to achieve freedom from the daily grind and to meet long term financial goals.

Benefits Of Working For Yourself

  • Achieve – The sky is the limit.
  • Vision – Your the one with the vision (for the company and/or product).
  • Destiny – You make your own destiny.
  • Freedom – You call the shots.
  • Profit – As owner, you reap the rewards.

What I Think Works

My thoughts on what works will probably change a lot over time, but currently I think one of the best ways to become a successful entrepreneur is to develop applications, websites, devices, etc that are an improvement to a larger company’s product in the hopes that they buy out your company.  For example, $10 million is a lot for an individual working the daily grind, but pocket change to large corporations.  Buying other companies is at the heart of how Apple, Google, Microsoft, Facebook, or any other major companies acquire new technology and features so it definitely works for some people.  Think of whatever your company is bought for as excellent seed money into the next.  The big “but” here is don’t undersell either.  If you can see a larger valuation for your company/product, stick with it and don’t take a buyout.

What Doesn’t Work – Writing Books

Apparently, writing books isn’t as profitable as you would think.  If you listen to the Entreprogrammers podcast, you’ll hear just how much they make on their books.  While I don’t remember the exact numbers they say, it wasn’t a lot (only a fraction of a good year’s salary).  It’s enough to make me think that unless you are some big publishing company its simply not worth your time and effort.

Posted by Chad Dotson in Programming, Software Engineering, Work, 0 comments

Knowing When You’ve Wrote Crappy Code

Note: This article was kicked off by one I read over at LosTechies.

We write lots of code, statistically speaking some of it is what we’d deem as “crappy.” If you’re doing things right and progressing in your career and your understanding; your definition of “crappy code” should change over time.  This is very important concept for a good Software Engineer, its one of the ways we get better.  We recognize our past coding mistakes and work to better them.

Dangers of Crappy Code:

  • It could hide technical debt.  “I don’t really know how or why this works, but here it is. Done.”
  • You’ve not taken the time to make what works, right.  This potentially leads to bloated code, duplication, and an overall poor product quality.
  • Is it robust?
  • It is, potentially, not very reusable.
  • Can I hand this code off to someone else and they understand it?

Preventing Crappy Code:

The prospect of writing crappy code should not prevent you from getting a project working.  However, it is very important to make it as right possible before committing the code changes to the repository.

  • Write self-documenting code.  Some developers may scoff at this statement, but self documenting code is very possible in just about any language.  Remember comments are your failure to communicate.
  • Remember to refactor, refactor, and refactor.
  • Ask for the opinion of a peer.  This should be someone you consider qualified enough to give an opinion.
  • Use “TODO” comments so your thought process is not lost and it will serve as a reminder that you must still make something right.  This doesn’t prevent crappy code from making it into a project but it documents its existence.

What To Do When You Find Crappy Code:

For the sake of this topic, lets assume you run across some crappy code 2 years into maintenance of a software product.

  • Identify why it is “crappy.”
  • Does it work or has it unknowingly introduced bugs into the system?
  • Perhaps leave a NOTE comment in the code, especially if it can add insight into the function of the crappy code.
  • Only change the code if it is within the scope of your current task.  Remember that it has worked for 2 years and changing it now could potentially introduce error.  If you do end up changing the code, attempt to make it right before you finish.  Also make sure to update your unit tests.

Are you Ready?  A Simple Test

Review a code base that you wrote 2 years ago.  Did you find “crappy code?”  The answer should almost certainly be a “Yes.”

 

Posted by Chad Dotson in Doing Things Better, Key Concepts, Programming, Software Engineering, 5 comments