Learning the Hard Way

Recently I was reflecting on the early days of my career and some of the lessons I heard and then learned.  I say it that way to indicate there was a difference in what I was taught or read, knew better, and didn't follow that direction, and then learned "Oops, I guess I should have listened."

Please consider the context of these lessons are unique and I am not trying to write a book to cover every scenario.  Think of these are a catalyst for thought, the intent is to make you think about these ideas and make your own decisions based on an alternate view.  Please excuse typos and grammar mistakes, I am not great at proofing my own writing.

Project Life Cycle

In college I learned of the SDLC and all of details of those steps.  SDLC is the System Development Life Cycle but I have heard it many times referred to as the Software Development Life Cycle.  Early in my career I did not need all of that Academic garbage, I have tight deadlines and know what I need to build.  Someone just told me what to build, I will build it and everyone will be happy.   Everyone was often not happy.  As it would be, I often built something that solved the wrong problem, did not scale because I didn't understand why I was building something and I would be ashamed if some of that code has not been deprecated knowing how terrible it was.  Ok, this may be a little excessive but the point is how important proven processes can be.  Many developers know of these processes but do not embrace them.  I am saying, I have seen it both ways.  Most often, the projects and even tasks that follow a process are far better than those which were plugged in to solve a small problem.

Moral of the story: When anyone asks you for anything, no matter how small it seems from the surface, ask "why".  Step back to the purpose and requirements.  Draft a high level design, confirm that design with a colleague or a client.  Develop, test, deliver and document.  I know this may feel like overkill for some tasks but trust me, you will usually learn that there is more to the request than just a simple snippet of code.

Manageable Code

In the beginning, I developed bad code because I didn't know better.  Then I produced better code, reduced lines of code and made many easily reusable components.  I would build functions or classes for everything.  I learned this lesson from my wife.  She loves to organize, to the point where it really means hiding things from me.  She will now ask me "Where would you go to look for this?" This is significant because she has almost no context of how I use something or why it's useful to me.  My career now has me working on many projects and then handing those off to a client.  Sometimes another team member will be the person supporting this in the future and as a final case, they will most likely throw some really strange requirement 1 week after launch.  I now consider coding from a perspective that considers that someone else has a totally different style and background from me.  I comment well, in come cases I cut and paste code so that it's obvious where they need to change something rather than using a complicated configuration or interpreting function.  I used to wrap everything in loops to reduce lines, now I make those things obvious.  This way, if some small parameter gets a slight change, it's easy to find that line, update it, and move on.

Moral of the story: Make code that anyone can edit despite their experience level and background.  Make code that is obvious and easy to change.  Organize your code considering "where would someone go to find and update this?"

Personal Development

"Wow, I should have done that better." During those early days I never reflected on what I was doing, have done, or where I was going.  This was not because I didn't want to get better or beat myself up with criticism (I actually enjoy doing that), I just didn't have time/energy for that and maybe didn't realize the value enough to make time.  That has changed.  After everything I do I try to evaluate it.  "Could I have written that code better?" "I wonder how people interpreted what I said?" "Were there any inhibitors on that project I should have addressed?" "Why don't they feel this is the right solution?" So many questions to ask.  In the end I do not have to rely on making the right choice spontaneously (which I know I am not great at) since I have already put thought into this.  I have a plan for this scenario; I have heard or had this problem before; now I also have an answer or solution or approach.

Moral of the story:   Evaluate each day and the events in it to understand the "why".  Then you figure out "how" to handle it next time and better understand "what" it actually is.  I borrowed that from Simon Sinek, I hope he doesn't mind my liberal interpretation.  I have learned to love these 3 questions.  I seem to ask them all the time now.

I hope this insight was helpful.  I consider myself young and have many years of learning to go but wanted to at least capture a few thoughts that have surfaced for me lately.  Please feel free to leave lessons of your own in the comments.

---

Brian J. has been involved in web design since 1997. He is the founder of True Vision Computer Services, Inc. His recent focus has been on web applications and information systems development.