Skip to main content

There is no "Right" way.

It's not that your way is not the right way, it's that everyone has their own right way.  So which is the right way?  Is there a right way?

Software development is full of discussions that revolve about the "right" way of doing something. The terms used in discussing software design, tools and implementation are so undefined as to make them meaningless.  Code is not designed and written in a vacuum, it's designed by real people in real companies, each with their own constraints and issues.  Code that may look like a hack could have been the result of an employee dragged out of bed at 2am by a company shirt that only cared that they they did not lose their personal client the next morning.  Everything must be looked at in context.  A project written to "Best Practices" may never be finished before development funding dries up.   Goals, vision, constraints and thoughts should be somewhat aligned for project to be successful (or at least enjoyable in development).

Buddhism is about understanding oneself, how everyone's thoughts effect their actions and that everyone and everything is interconnected.  Each engineer has their own "Best Practice", just as managers and the company it'self does.   Engineers have goals that may or may not be the same as the companies.  Managers have techniques for managing that may seem out of place for staff.  Companies may have a vision that is fully (or not) understood by the sales staff.  It's all connected.

How does this all come together for software development and you?  You can only do so much but here are some thoughts:

  • Don't try to convince others of your beliefs. You can only express yours thoughts.  
  • Respect how others may think.
  • Work at understanding your managers and company's goals.  Somethings they are undefined and that is ok to, it's their choice and that may be the what they want.
  • Perform your work so that if fits with the people around you.  It may not be what you really want, but it may be what is needed.  It does not change you as a person to change your coding style, use a different toolkit, etc.
  • Remember of what is really important in life and what brings you lasting happiness.  I'm pretty sure its not getting in an argument over design elements.
Next: What code makes you happy?

Comments

Anonymous said…
Wow...this is very insightful and very helpful for a rookie developer. Thanks for writing this.

Popular posts from this blog

My Current Desktop and Happy Vining.

It's been a big switch when I quit my old procession (Software Engineer) and ventured into the unknown.  So this is my current desktop.   First it's a REAL desktop and not a computer screen. Second, I've had to learn a whole new set of tools.  You would think a pencil is just a pencil and a paint brush is just a paint brush, but noooooo, they are tools into you mind and that's what needs re-tooling. The tactual nature of these tools and operation as much more rewarding (and frustrating too) than typing code in an IDE.   That had it's incentive but that well went dry and life changes,  so I changed. The pleasure of creating colors (no RGB involved) ad hoc wise is interesting.  Getting the technique to merge them on paper is very tough.  You do not know what you're going to get, so you just have to go with it. I'm glad that I can do a lot of other things instead of Software, but I hope that others in my past procession work on other pa...

3rd Try is a Charm

I've been trying to draw / paint these barns for a couple of years but never felt or got them right.  This time I think they turned out right. So What went wrong before and what's right now with this drawing?  This time, the light was right.  It's coming from the upper right and the shadows just looked right.  The other thing is the corn field on the left had to "be in season", otherwise it's just a plowed field.  I had taken other photos from different angles but they never felt right.  This angle has the road, power lines, corn field, etc. all leading to the right.  The shadows on the lower right helps fill in that corner (don't forget about the corners!).  The last part is trying to draw (ink paint maybe) the trees in the background.  Not so easy when they are kind of a blob is green shades. So yeah, it's composition that is king.  Many times I just don't see it until the drawing / painting is finished and when it's right it feels goo...

Thought Patterns

I know how I work.  How a think about, visualize a problem and go about mentally design a solution and implement it in code.  My thought pattern works pretty well for me on most occasions, but not always. There are times when I have a force myself to change my thought pattern because of the problem I'm solving requires a different mindset.  Anyway, this posting is about how I work most of the time.  Here is goes. I quickly break down a feature into operations that are required to exists and tackle that code first.  My thinking is that, if I can solve the primary issues first, then secondary features will fall into "known knowns" and I can address those at anytime (and sometimes at my leisure) and this allows me to meet my internal timeline. If I addressed features and operations that are not primary first, then I feel I risk my (and the projects) timeline without addressing issues that allow the feature to operate.  You may have seen this occur where...