AKF Partners

Abbott, Keeven & Fisher PartnersPartners In Hyper Growth

From Technician to Engineer

We’ve had a couple posts on this topic of engineer vs craftsman vs technician but I found myself in the past couple of days discussing this topic in two different settings and thought it would be fun to revisit on the blog. I started the conversation with a post that quoted Tom DeMarco concluding that “software engineering is an idea whose time has come and gone.” Also quoted was Jeff Atwood stating that “If you want to move your project forward, the only reliable way to do that is to cultivate a deep sense of software craftsmanship and professionalism around it.” Marty picked up the conversation in another post stating that:

All of this goes to say that software developers rarely “engineer” anything – at least not anymore and not in the sense defined by other engineering disciplines. Most software developers are closer to the technicians within other engineering disciplines; they have a knowledge that certain approaches work but do not necessarily understand the “physics” behind the approach. In fact, such “physics” (or the equivalent) rarely exist. Many no longer even understand how compilers and interpreters do their jobs (or care to do so).

I think it is possible that we are seeing the evolution of our discipline as it struggles to determine what its final form will take. Computer science, information technology, software engineering, and other related disciplines are all relatively new fields of study. With a new discipline it should be expected that definitions and themes will need to be stretched or reconsidered.

Software engineers, similar to other engineering disciplines who are taught more “true” laws such as Newton’s or Faraday’s, also undergo something of an apprenticeship once their degree is conferred. Mechanical and electrical engineers work beside senior engineers who help them transition from the theoretical to the practical. Software engineers are often apprenticed in the same manner by more senior engineers. If the practical implementation of one discipline is considered engineering because it is based upon laws and principles, I would argue that the principles of architecture for scalability are of a similar nature. This in fact I think is a strong differentiator between technicians and engineers within the software development discipline. A technician can write code, setup a database, or administer a server. An engineer can architect a database or system or pool of servers such that it can scale. We’ve written several posts about the principles and patterns of scalability and a large part of our book is dedicated to these principles. Are these sufficiently established to be called a principle as defined in Wikipedia?

A principle is one of several things: (a) a descriptive comprehensive and fundamental law, doctrine, or assumption; (b) a normative rule or code of conduct, and (c) a law or fact of nature underlying the working of an artificial device

I still like the idea of software developers as craftsmen and -women but as I concluded in the other post, that discussion for me is as much about organizational size and control as it is anything else. The technician vs engineer discussion I think is best held in the light of are they or are they not applying laws or principles. As the American Engineers’ Council for Professional Development defines engineering “The creative application of scientific principles to design or develop…” Have we as a discipline, especially in terms of scalability, advanced enough to call what we use “principles”? Let us know what you think.


Comments RSS TrackBack 4 comments

  • Ori Lahav

    in October 7th, 2009 @ 13:57

    Fish
    I liked this post and the discussion about Engineers Vs. technicians.
    We all know that titles doesn’t really matter, what matter is how creative, resourceful, and knowledgeable a software developer can be. And maybe most important how does the organization encourage the developer’s creativity.
    Sometimes we use the term “implementing” for code writing instead of developing. Implementing usually means “here is the plan… implement it” where developing means “here is the general idea… develop it to a product”.
    Many organization still employ implementers and not developers and call them engineers.
    In terms of scalability – yes, you do have to know some principles of scalability in order to take a scalability problem and solve it.
    Actually, I haven’t seen one architecture similar to the other just because the scaling architecture is tied deeply to the product. However, many of them share the same scaling principles. You can find 2 tiered architecture and 3 tiered architectures that both use the “scale out” principle.
    Like every craftsman – the ability to take material and principles and make a different (scalable) solution for each problem domain is pure professionalism.

    phew – it came out a post already


  • James

    in June 27th, 2012 @ 14:16

    The fundamental difference between engineers and technicians is that Engineers develop/design systems while Technicians support those systems.

    As such, Engineering and Technology are complementary fields. Engineers need to start from a theoretical framework in order to develop/design systems while technicians need to understand how those systems work in order to support them.

    That fundamental difference between Engineers and technicians gives engineers a career advancement advantage over technicians because engineers usually manage the development and implementation of their systems, which are to be supported by technicians.


  • read more

    in October 22nd, 2012 @ 02:09

    I appreciate you sharing this blog post.Really thank you! Really Cool.


  • Maude Farnell

    in October 27th, 2012 @ 07:05

    My partner and I absolutely love your blog and find many of your post’s to be exactly what I’m looking for. Does one offer guest writers to write content in your case? I wouldn’t mind producing a post or elaborating on most of the subjects you write in relation to here. Again, awesome blog!