Pragmatic vs Theoretical Development and Corporate Bureaucracy Lessons From my First Job Onward
I tell a story about my very first full-time software job to my developer friends because it really sets the development practice tone of reality to me.
It is a story of how a pragmatic developer hits the world of theoretical and bureaucratic based development.
The First Job Story
The first day I was on my first job after graduate school I was given a simple task of creating several daily KPI reports for a plant manager. A simple, get the kid's feet wet sort of assignment.
From my point of view I was eager, but not prepared for the corporate culture I had entered.
Up to that point I had written code on my own, some for graduate work, some for personal projects and fun. But I was used to defining problems, the final goal and getting it done.
The only friction I general had was my own knowledge limitations.
I really do not remember the content of those reports, but I do remember Sybase, Stored Procedures and PowerBuilder were the platform.
I hit the ground running and knocked out a solution for the plant manager in 2 weeks (10 business days). He was really excited to finally have this information available anytime he wanted.
The reports would eliminate a lot of printed material the shift managers would leave. This would make his mornings more efficient and he could easily compare production over time.
I was excited because I had pleased my customer (the plant manager) with my first project.
I was very proud of myself and was beaming confidence.
All I had to do now was get my new reports integrated in the nightly system updates.
(play evil music here)
This is where the story goes sideways...
This is where corporate culture kicked in...
My first job was for a textile company, with plants all over North Carolina and a few other states. Even though I was in Greensboro, the headquarters I was not in the IT building. My office was at one of the plants, away from the rest of the company's developers.
I was in an office with engineers, with a culture of making things work, even it was a temporary fix till a permanent solution could be implemented.
You know, pragmatic.
If you are an enterprise developer or employee of any kind you probably know where things are heading.
I went to submit my code for production deployment. Which to me meant it would be available the next day in a worse case scenario.
No one had taken the time to tell me how to get my code deployed yet.
So I asked...
I was quickly introduced to paperwork that would make the IRS proud.
So I filled out the forms (which if I remember correctly took about an hour just to find them all), submitted them and fully expected to have my new reports available to the manager in a few days.
Boy was I wrong!
A week goes by and I get a phone call telling me that I needed to have three code reviews!
- Stored Procedures
I did not even know what a code review was!
I am a self taught developer and had degrees in Polymer Chemistry and Textile Engineering. I had done a lot of development all by myself.
So I said, fine, when and where. The developer version of 'Bring It!'
With confidence and bravado beaming I drove down the street to the IT building fulling expecting this to be a quick adventure.
I was ripped all over the place in the first code review (PowerBuilder), it was brutal.
The other two reviews were just as bad.
I walked away with 7 inches of 3 ring binders containing PowerBuilder coding standards.
Then came the SQL coding standards and a bloody introduction to an extremely hard to use CASE tool.
I really could not believe what just hit me.
Why did they not tell me about the code reviews and bureaucracy in the first week?
I still have no clue.
Lessons Learned For the Rest of My Career
Looking back having a peer code review is not a bad thing. Even though I am still very independent and plan on staying that way, reviewing code with a competent peer is a nice thing.
I try to remain consistent in my coding practices. I even try to state current with trends.
And by trend I mean what is cool this week.
I also think my seasoning helps me remain calm as I see new things pushed every week. Today I ignore most of them and still just get things done.
That can be difficult because technology, implementation patterns or techniques changes rapidly.
Here today, gone tomorrow.
But I do like to share code with peers and get feedback, I do want to be the best I can after all.
The CASE tool on the other hand was bad and I still think pretty useless. I saw it as only adding a great deal of impedance to a simple task.
Thankfully I never see CASE tools being used. We have better ways to craft data models. Plus NoSQL is pretty common and mentally that works better for me.
The company had thousands upon thousands of custom data types. This means there were literally hundreds of data types that were nothing more than an integer with a new name.
Of course I had to pick the right one and hope I was not wrong, etc.
The CASE tool itself was very complicated and I could easily have 20-30 individual windows open at once. One of the worst User Interfaces I have ever encountered.
I would have preferred a command line tool! And I hate jockeying the command line.
Ultimately, the task I satisfied the paying client with in 2 weeks took another 6 months to get deployed.
By that time the manager had solved his problem another way and even forgot I had created the reports.
Ultimately the reports were never used, which to me is the ultimate insult to a developer.
It also wasted several thousand of the company's dollars (I spent about 2/3 of my time on this project for 6 months remember).
The code review did not change the operation of the application. It did help me code more inline with the company's standards and be more organized with my coding.
That was actually productive and helpful. I had never used PowerBuilder (don't worry it is long gone), and have not since. The corporate guidance was helpful and I do encourage something like this for any team.
The CASE/SQL side of things was just atrociously unneeded.
This is why so many business units utilize 'shadow IT' to get solutions done. Hence the large number of rouge Access applications sitting on assistant's and manager's computers. This will always be the case.
How Customers Deal With Bad Theoretical Practices
Today I think common IT bureaucracy and project theories are why SASS solutions are very popular. A business unit can create an account and get their job done.
Internally they would be looking at a very long delay before an in house tool would be available. Plus it would code 10-30x more, include more bugs and less features.
I consider myself a very pragmatic developer.
I make mistakes, everyone does.
Most of my biggest mistakes come from putting energy into trying to abide by theoretical development guidelines.
I see them all the time, their practitioners are loud, but a minority.
The problem with the first job story is the IT department failed to educate me on their standards. They also had a small faction that focused solely on theories, not productivity.
Their system and culture was broken in two key places, for me and the plant manager at least.
Over the years I have seen so many 'theoretical' arguments about different ways to write and architect code. Sometimes the arguments pan out and become good standards.
Most of the time they are just babbling.
I have learned to ignore most of the chatter.
My Core Engineering Beliefs
Thousands of projects of various sizes, industries and teams have taught me so much about developing quality software in a timely manner that can be maintained.
Here are some things I believe in:
- Highly decoupled systems (hello serverless)
- REST APIs
- Code generation/scaffolding
- DRY and Single Responsibilities
- Writing Code as close to the metal as you can tolerate
- automation, I mean automate as much as possible and write as little as possible (see code generation)
- Performance is the First feature requirement, even if it is not part of the customer provided spec
- Software is never done.
- Ship fast, update frequently and deploy often
- Don't be afraid to break things. Just be prepared to roll back or repair quickly
I do not know about you, but my experience has proven out that clients want something they can touch as fast as possible. Getting a site online sooner typically means the client makes money sooner and they pay you sooner (both good).
This is good, as long as the client will continue to let you update the application and make it better after it is in production.
Sadly most will not. Then they complain the software is incomplete.
There is a delicate balancing act that needs to be managed. You know those pesky expectations.
There are many more examples to point out in today's software development climate.
The bottom line you should always remember: The Client could care less what technology you use to solve their problem. They just want their problem solved today.
So solve it as quickly as you can, minimize the introduction of new problems and use continuous improvement to make the solution better over time.
My first experience in the enterprise was shocking. I think many young developers have similar experiences. I think the irony is college is supposed to be filled with academic theory, not business.
I was lucky, my professors taught us pragmatic engineering over theoretical computer science. One of the many life lessons I took from my academic experiences.
Don't be afraid to not jump on the latest and greatest development theory and shiny balls.
There will be another 'you have to do it this way' next week, maybe tomorrow.