Skip to main content

Graduating from Programmer to Engineer: Benefit of doing total life cycle development.

A thread in the java forum on Facebook posed the following question:

"What do you think: is it better to learn
1. HTML and CSS
2. JavaScript
3. Database design
4. SQL
5. Java  "

First off, this question really applies to those that have the aspiration of doing what is called total life cycle development, people who wish to be generalists of the entire software development stack for an application. To touch all aspects from class design to UI development. This is always good experience to have but often developers are segmented into each tier as each can be it's own world of complexities and issues, languages and best practices. However, doing a project end to end can provide a great deal of the talent that comes with experience that turns a programmer of code into an engineer of systems. I have full belief that ones options for growth as an engineer and in the field are far greater once engineering skills are gained beyond the sandboxed mind set of "programmers". I have spoken on the difference at length in an other post.

I can say having embarked on a large project over the last 11 years that originally started with my novice understanding of the java programming language that it was far more instructive to start with the core elements of the business logic and that required that I fully understand the OO features that java could provide to significantly collapse the difficulty of coding a scalable, extensible, db agnostic, web based platform BEFORE any such platforms existed in the wild.

The bulk of the code that I wrote for persistence, scalability, security and workflow was purely de novo as there were no third party solutions to plug in and use at the time (2001). This was a great situation as it forced me to create what I needed without pollution from the ideas of other implementations which could have detracted from my ability to design the optimal class hierarchy. The drawback of course was that design time for each component would be required but that meant I could get the practice with obscure aspects of the language that would cement engineering (as well as) programming mastery. (There is a big difference!)

So, I needed to learn about the details of the reflection API, I needed to fully understand RTTI and had to realize the power of run time extensability and writing a custom class loader. I had to fully understand how to use threads, control their populations, segment their access to memory, disk and data resources without creating pathologies (deadlocks,race)....I needed to fully understand how these pathologies could emerge very differently under scaled and loaded conditions. Understand the impact of the network on the architecture, the impact of load on the union of the two, address geographic load and scalability. In short all the big giant problems of enterprise software development came into play over the course of the development.

I spent almost 2 years coding core classes before I even got to client code implementations in user interfaces. The db schema was designed in parallel with the object structure and served to cement my skill with SQL and the need to support a variety of DB vendors enabled me to explore creation of a persistence API that was agnostic to vendor DB's. All of these experiences were of huge value as they allowed me to encounter the sticky problems that are often in the purview of those that have been in the field. You don't get these problems in cs 402 on advanced data structures...even if in some ways data structures are involved in solving those problems...they are in a distal way...these is what I mean by engineering versus programming.

In summary, greater value I think can be found by starting with the core language, that ties almost invariably to understanding the data model (db) and then later when approaching the UI, the client coding issues present along with the issues revolving the templating technology (jsp/php..etc.) dynamic page scripts (javascript/ajax), services (json/xml) and design (html/css).



Prioritizing the business logic is the correct way to look at a problem. Coming from a public corporate environment, if you can sway your bosses (they hold the purse strings), it is approved. In Entrepreneurship, the same is true especially when asking for VC/Angel funding...

Popular posts from this blog

Highly targeted Cpg vaccine immunotherapy for a range of cancer


This will surely go down as a seminal advance in cancer therapy. It reads like magic:

So this new approach looks for the specific proteins that are associated with a given tumors resistance to attack by the body's T cells, it then adjusts those T cells to be hyper sensitive to the specific oncogenic proteins targeted. These cells become essentially The Terminator​ T cells in the specific tumor AND have the multiplied effect of traveling along the immune pathway of spreading that the cancer many have metastasized. This is huge squared because it means you can essentially use targeting one tumor to identify and eliminate distal tumors that you many not even realize exist.

This allows the therapy for treating cancer to, for the first time; end the "wack a mole" problem that has frustrated traditional shot gun methods of treatment involving radiation and chemotherapy ...which by their nature unfortunately damage parts of the body that are not cancer laden but …

Engineers versus Programmers

I have found as more non formally trained people enter the coding space, the quality of code that results varies in an interesting way.

The formalities of learning to code in a structured course at University involve often strong focus on "correctness" and efficiency in the form of big O representations for the algorithms created.

Much less focus tends to be placed on what I'll call practical programming, which is the type of code that engineers (note I didn't use "programmers" on purpose) must learn to write.

Programmers are what Universities create, students that can take a defined development environment and within in write an algorithm for computing some sequence or traversing a tree or encoding and decoding a string. Efficiency and invariant rules are guiding development missions. Execution time for creating the solution is often a week or more depending on the professor and their style of teaching code and giving out problems. This type of coding is devo…

AgilEntity Architecture: Action Oriented Workflow

Permissions, fine grained versus management headache
The usual method for determining which users can perform a given function on a given object in a managed system, employs providing those Users with specific access rights via the use of permissions. Often these permissions are also able to be granted to collections called Groups, to which Users are added. The combination of Permissions and Groups provides the ability to provide as atomic a dissemination of rights across the User space as possible. However, this granularity comes at the price of reduced efficiency for managing the created permissions and more importantly the Groups that collect Users designated to perform sets of actions. Essentially the Groups serve as access control lists in many systems, which for the variable and often changing environment of business applications means a need to constantly update the ACL’s (groups) in order to add or remove individuals based on their ability to perform certain actions. Also, the…