Concise Code is NOT Always Production-level Code !!!

Best Laid Plans of Mice and Men

Just because you want your code to be concise does not always mean that is the code you will be placing into Production !

At the end of the day, once all the defects have been fixed, the code you find in production will probably not resemble the code you began with when you felt it was as concise as possible.

The fact today is that most software developers have no idea what production-level code looks like because they themselves are not responsible for working on production-level code.

Lack of Mentoring from the More Experienced

Even those favored few software developers who are prized by corporate america as being senior talent do not seem to know what production-level code should look like.  They make far too many assumptions about the code they wish to see.  They are far too willing to trust in their assumptions even when their assumptions may be leading to Bugzilla more often than not; but then they almost never get to make the connection between the code they wish to see and the code that produces bugs – others work on their bugs.  Projects are manned by many more developers than might be required otherwise; projects are perceived to be far too complex for individual contributors and there are very few strong individual contributors because… corporate america does not seem to want to grow strong individual contributors – pair programming makes individuals weaker than would be desired – individuals are not being asked to be strong contributors – individuals are not being encouraged to work on their own projects when not at work and quite frankly most individuals who write software on the job have any real interest in becoming strong individual contributors.

Since there are very few strong individual contributors available to teach others, to pass along experience and knowledge, very little is being learned by the army of developers that inhabit corporate america – virtually none of them, that I have met over the years, seem to know what coding patterns lead to Bugzilla versus those that do not.

Those who fail to learn from their mistakes are doomed to repeat them…

Because there are very few developers who know how to avoid the mistakes that lead to Bugzilla the development cost for corporate america is very high.  Millions of dollars are being pumped into code that is becoming increasingly difficult to maintain because there are far too many people working on that code, stirring the pot, turning their code into meaningless goo.

Management, largely in denial, wishes their code to be more maintainable without so much as knowing how to achieve that goal.

Highly maintainable code may not appear to be highly readable code – the two are not always the same.

The Tactical Advantage of not having to waste time on Unit Testing

The greatest threat to corporate america may just come from those few who have maintained their ability to produce working code quickly without the need to waste time on Unit Tests and such.

Unit Tests are only required by those who do not really know how to produce robust code, assuming the reason one wishes to use for producing Unit Tests is to ensure their code is working otherwise Unit Tests are a reason to not produce and maintain adequate documentation for others to read.  Either way, Unit Tests are being sold to software developers as being a requirement when the opposite is more true than not.

Any company that can break free of the shackles of Unit Tests will have a definite advantage in the marketplace.  Shorter time to market.  Shorter less costly development cycles.  Fewer developers on-staff.  Greater profits.

Strong Individual Contributors can produce complete products quickly

I have done this myself.

Coded a complete product rewrite in 30 hours and earned an additional 16 weeks of work for my efforts.

Was this difficult ?

No !

Was it profitable for the sponsoring company ?

Yes !

Is this a threat for corporate america ?

Maybe !

 

Advertisements

36+ years :: Software Engineer

This is by no means a complete accounting of all 36+ years – additional details may be added at a later time.

When you are self-taught there is NOTHING you cannot teach yourself and NOTHING you cannot do.  Trust me, I know !!!

I taught myself every single computer language and technology found below.    From time to time I also taught others.

1974

There are no IBM PC’s at-all, anywhere !!!

There are hand-held programmable calculators from Texas Instruments and other companies.

There is NO Internet !!!

There are computer magazines like Byte and others.

Taught myself top-down structured programming by reading about it in various computer magazines and other sources however I still had to understand what top-down meant and trust me I did know and still do !!!

1978

Joined the USAF as a grunt. (1978-1983, Honorable Disacharge)

Worked as a Logistics Clerk in the USAF on Guam.

1979

Bought a Radio Shack TRS-80 from a magazine ad and had it shipped to Andersen AFB, Guam.

Learned Z80 Assembly Language.

Learned BASIC – actually I already knew BASIC from my years in High School when I was reading all about this language by reading other people’s code; this is why I can read other people’s code so easily – because I began by reading other people’s code.

1980

Relocated to Edwards AFB in California.

Modified TRS-80 to run CP/M-80 with the flick of a switch.

Learned CBASIC – already knew BASIC which means CBASIC was not a problem for me.

Wrote a Z80 Single-Stepping Debugger for CP/M-80 in Z80 Assembly Language; my debugger was able to step through RAM and ROM with equal ease.

1980-1982

Attended Chapman College at night, worked as a Computer Operator by day – tutored other students whenever I was in a CompSCI class. Used computers to help me with my Calculus studies because doing this was easier for me than anything else; when you know how to write code to get things done you write code to get things done.

1981

Wrote a 3 part magazine article for 80 Microcomputing that was published for which I was paid  – this launched my professional career as a software engineer.  This 3 part article had something to do with Floating Point Arithmetic for the TRS-80, as I recall.  Let me know if you can find a copy of this article in your archives.

Directed traffic for the Air Force at one of the VIP Parking Lots at EdwardsAFB for one of the early Shuttle Flights that landed at Edwards during 1981, probably for STS-1 or STS-2.

1982

Learned FORTRAN.

Learned PL/I and was allowed to spend time on USAF Mainframes [IBM 360/2075J and 370/3033N] during the weekend hours – was assigned to a Computer Operations Detachment. This was quite fun although I had to buck the system to make this happen.

1983

Exited the USAF, honorable discharge after 5 years of service at Lowry AFB (Lowry AFB was closed in September 1994).

Began working as a professional consultant for a company called CACI at Lowry AFB in Denver CO – Lowry AFB no longer exists as an active Air Force Base.  Served as a Systems Analyst as an Air Force Civilian Consultant.

1983-1989

Began working with MS-DOS in 1983 while working for the USAF via CACI.

Was given an annual budget of $10k to spend on whatever software tools I wanted to buy at work.

C programmer – Wizard C Compiler which later became the Borland Turbo C Compiler and Microsoft C which was Lattice C.  Wrote a whole lot of C during this period of time.

Salivated over working with APL but could never quite convince anyone I should be given the opportunity or the tools to take this on.

Got introduced to Golden Common LISP but was never allowed to use it on the job for any projects.

Began working with non-relational databases like B-Tree databases and others; there were no desktop relational databases at this time – heck there really weren’t any Desktops other than DeskView since MS-DOS ruled the business world at this time.

1986-1988

Began working with Unix in the form of System V and Berkeley aka. Xenix; learned it was very easy to deal with Unix as an Administrator.

1989-1991

C Programmer – Wizard C Compiler and Microsoft Quick C in Los Angeles, CA under contract with a local software development house. Wrote a whole lot more C Code during this period of time.

1990

Founded Hierarchical Applications Limited, Inc. primarily as a think tank.

Produced C-Armor Toolkit – featured some rather advanced multiprocessing support for the C language under MS-DOS, coded this from scratch in parallel with another project at work I was not able to be assigned to – my product was better by design.  Featured overlapping windows with a process tied to a window or a number of windows – windows could be animated over/under other windows while being updated in the background.  Obviously wrote a whole lot of C Code during this period.

Began working with MS Windows 3.0.

Began working with Win16 – there was no Win32 API at this time.

1992-1996

Smalltalk Programmer – Digitalk Smalltalk and Parc Place Smalltalk

Continued working with C during this period.

Began working with OS/2.

Began working with Windows 3.1.

1993-2011

Began working with Visual Basic with version 3.

1995-2011

Began programming Python

Digitalk Smalltalk and Parc Place Smalltalk  languages died as a commercially viable languages by 1999.  Parc Place and Digitalk merged in 1995 but failed to respond to the Java threat.

Began working with Windows 95.

Began working with Windows NT 3.1.

1996-2011

Java Programmer – Java Servlets mainly

ColdFusion Programmer – ColdFusion 3 through ColdFusion 9

Began working with Windows NT 4.0.

1995

Bought a copy of the Futuresplash Animator which later became Macromedia Flash.

1996-1999

Built and operated a successful Web Hosting/eCommerce Service via Hierarchical Applications Limited, Inc. with 250 customers for almost 3 years.  Work was based on ColdFusion and other languages like ColdFusion.  You have to know something about programming and I.T. Infrastructure to get a successful operation online – each server I had during this period cost me something like $20k and I had something like 7 servers online at a Colocation Facility in Dallas TX.  I also coded 100% of the software I used for my part of the business that included eCommerce support for all my customers.

Taught myself how to leverage the power of the TCP/IP Stack without ever having to know how the TCP/IP Stack works other than to watch what happens when multiple NICs are plugged into the same computer – let’s just say I was able to leverage TCP/IP in what was a creative use for me – working with more than one network at the same time was fun.

1996-2011

JavaScript programmer.

HTML/CSS programmer.

1999-2011

Began programming Flash and Flash related technologies.

Began coding REST Web Services using Flash in 1999 however the term REST was not defined until 2000.  Coded a large number of Flash Applets that were connected to back-end databases, quite the trick at this time, all things considered.

Began working with Oracle 8i Database.

Began working with Sybase SQLAnywhere.

Began working with SQL Server 6.5.

2000-2001

Began working with Windows 2000.

Began working with SQL Server 7.0.

Began working with C++ and crafted a kick-ass Mod for Tribes 1.0 that featured some really cool weapons and other game elements that were not generally available in that game in other mods; no other Tribes 1.0 mod had a heat-seeking missile made from the disc weapon but mine did for several years.

2001-2003

Began working with Windows XP.

Began working with Visual Studio .Net 2003.

Continued programming VB.Net via Visual Studio .Net 2003.

Began working with SQL Server 2000.

Began working with Oracle 9i.

Began programming C# because it is just another name for Java and Java is just too easy to program since 1996 for me.

2003

Began working with Oracle 10g.

2003-2009

Began working with Windows Server 2003.

Began working on the EzAJAX Framework in 2003 this was a full 12 months before GMail was released.

2004-2007

Perfected EzAJAX and the underlying techniques that have not been reproduced by any other AJAX Frameworks since.

2004-2005

Coded a complete Content Management System for SBC based on ColdFusion MX 7 and JavaScript/HTML/CSS that featured visual inline content editing and a complete Source Code Control System  – coding took no more than 4.5 months.

Began working with Flex 1.5 which was then embedded in ColdFusion MX 7.

2005

Began working with SQL Server 2005.

2006-2011

Began working with Flex Builder 3.

2008

Founded Vyper Logix Corp.

Began working with SQL Server 2008.

2008-2009

Began working with Windows Vista and Windows Server 2008.

2005-2011

Python Programmer, Stackless Python – began in 2005 in earnest when I was told the Python Language was considered to be “difficult” but of course there is nothing difficult about Python.

PHP Programmer.

Ruby Programmer

Perl Programmer

Erlang Programmer

MySQL 5.x, 5.1 and 5.5

2007-2008

Successfully integrated Python into Adobe AIR Apps 2 full years ahead of Adobe AIR 2.x that also supports this sort of thing.

Began working with Oracle 11g.

2008-2011

Perfected methods for the optimization of Ruby on Rails servers that use the Mongrel Web Server to achieve 250% better concurrency than can be achieved out of the box.

Perfected the first Content Management System known as VyperCMS using Python 2.5 and Ubuntu Linux and Windows used MySQL 5.x; the ORM used by the core of this product would allow virtually any relational database to be used in-place of MySQL should the need arise.

Programmed a method for Python Django Apps to be plug-n-played in VyperDjango; this opens the door for Django Hosting Operations that feature the ability for Django Developers to simply upload their apps without having to be concerned about FastCGI issues or the like.

Began working with Google App Engine with Python, Ruby and Java.

2009-2011

Began working with Windows 7 and Windows Server 2008 R2.

2009 – 2011

Began working with Flex Builder 4 also known as Flash Builder 4.

Began working with SQL Server 2008 R2.

Rolled a complete product for AmazingFacts.Org as an individual contributor in 15 short weeks; the prototype was completed during the initla 30 hours of work – this product has gone into production.

Perfected a common API for Mac based Adobe AIR 2.x apps to consume Windows based files without regard to case and naming issues.  This means Adobe AIR 2.x Apps work the same for Windows and Macs in relation to file naming conventions.

What can you do with 36 years of software engineering experience ?

The easy answer is…

Anything you want !

The up-side of having 36+ years of software engineering experience is…

Knowing how to write optimal code that will work from the get-go without having to think about it much.

This is something those who have less experience just cannot grasp.  They want to write code that runs fast all the while ignoring the obvious reasons bugs appear in their code.  Spend just enough time writing software on various platforms with various languages and after a while you learn why bugs appear in the first place.

Inexperience causes bugs.

Inexperience thinks performance means having to throw-out making their code robust and flexible.

Experience knows performance should be balanced against flexibility and that robust code will execute just as quickly as less robust code even when it seems there is more code that must be executed.

After more than 36 years of software development experience I can…

Learn any language in 3 days or less – believe me when I say I have done this and doubly faster when the language is ALGOL-like, those of you who are reading this but don’t know what ALGOL is might want to do some research.

Think algorithmically – I see the algorithm in my head and then I write the code – it’s just that simple.  Actually I see the code assemble in my head and then I write the code – the actual code that appears to me is more like pseudo code than anything else but this just makes good sense.

Able to handle code of any complexity – doesn’t matter to me how complex the problem gets, finite state machines are just as easy for me to code as the simplest loop or simplest Boolean logic statement.

Able to make sense of whatever code I may be exposed to – doesn’t matter to me who wrote the code, I am just as able to make sense of it as-if I coded it myself.  Case in point, pyPDF is a common Python toolkit that knows how to read and export text from PDF files – pyPDF does not know how to export the text from a PDF in the same order that text appears in the PDF (left to right, top to bottom); seems like what I am saying doesn’t make sense – just use pyPDF with enough PDF files and you will see what I am talking about.  I spent several hours with pyPDF and played some hunches and now my version of pyPDF knows how to export data from my Bank Statement PDFs which is helping me gather electronic records for my tax purposes to augment my normal accounting process.

Able to code shrink-wrap software projects with ease.   What’s the difference between normal software and shrink-wrap software ?   Hey, when you put it in shrink-wrap you expect it to work and so my production code does work because I know how to write robust flexible code.

Ability to see what can cause software bugs just by looking at the code.  This allows me to write code that has fewer bugs, when given the opportunity to do so.

And more…

Why don’t more hiring managers value what I can do ?

If you were marooned on a desert island with only local natively available foods to eat your whole life you would never know what a fine steak tastes like nor would you want to eat one if given the chance.

Or, if you spent your whole life eating at a fast food joint and that is the only food you ever knew existed you would not want anything better just because someone offered to something they knew was better for you.

I know the value of what I do best even when others do not but then I am rarely given the ability to explain to anyone why my approaches may be better and so I do my best work for myself most of the time.  If more people had open minds about their abilities to write software and they wanted to learn I might get more opportunities to demonstrate why I like to write software the way I do.

I do have an open mind and I do like to learn from others and I take the time to give ample though to why I am being told to write software the way others, who have less experience than myself, want me to present my work upon their inspection.

Software bugs are based-on assumptions that fail.

This is a fact although not every software developer seem to understand this.

Whenever you made an assumption that proves to be false your code will have bugs and the original intent of your code will fail to be realized.

BTW – I began writing software in 1974…

I have been self-taught ever since and I have managed to teach myself a whole lot with a whole lot left to learn.

Pandora is off my Droid !

I had to completely remove Pandora from my Droid earlier today because…

Pandora has become useless !

Pandora has been doing everything they can to make me pay for their service, I am sure this has been the experience of others too.

Pandora began cutting some songs short – far too many for some kind of random anomaly as-if it was my Droids fault.

Pandora then began playing commercials which I could care less about – commercials are easy enough to ignore.

Pandora then released something new… they chose to completely remove me from my channels.  I had just enough channels so I could always stream music I like to hear but as of this morning I was not able to reach my high prized channels and so I chose to remove Pandora completely.

Pandora has gone from being a must-have Droid App to being useless in just about 1 year.  Last year about this same time I was enjoying Pandora like there was no tomorrow during my 65 miles per day round-trip to/from the office.

This year I have been enjoying Pandora during my 130 mile office round-trip.  Today I will be enjoying my iPod Touch because it seems Apple knows how to play music for me when music is what I want to hear.  Sure I could use my Droid for this but at the moment I am not happy with Pandora so I will be using my iPod Touch until I feel the need to crank my Droid into playing some tunes.

I would personally be happier if I could build my own streaming music server so I could use my Droid to play tunes while on the road but what the heck – maybe Apple should get some kudos for making it pretty easy to use an iPod Touch for playing tunes.

Damn you Pandora !!!  Damn you to hell !!!

Is this Smart Code or Cute Code or just Code that will Break Someday ?!?

Consider the following chunk of JavaScript code:

Look like perfectly good code, doesn’t it ?

And this is the code one unnamed senior software engineer at one fortune 500 company told me recently to write.  He just wanted to see fast codes.

But where might this code break. if it were to break ?

Code Chunk #1

Each of these red arrows tells us where this code might break because each of these red arrows highlights an assumption that could be false just as easily as it could be true.

If you wanted this rather simple-looking JavaScript function to execute without failures it would look like this:

Code Chunk #2

In this second chunk of code we have the same functionality as the first chunk of code with a possible performance loss of something like 0.01% per 10 million iterations or negligible performance cost but ALL of the previous assumptions have been handled and accounted for.

Which code is better for your needs ?  The hastily written code that has 3 assumptions that could fail OR the carefully crafted code with fewer points of failures.

In all fairness the guy who directed me to write the code that could fail works for a major publicly traded company that is known to have a lot of code defects to worry about – something like 800 defects that had to be knocked down to something like 200 defects in about 4 months time.

What is the cause of their defects ?   Hastily written code, maybe ?

Sure it seems like the hastily written code with fewer lines to think about might run faster and it might run 0.01% faster if there were 10 million iterations however the cost if that hastily written code breaks would be far greater than if the more carefully crafted code had been written in the first place.

Why didn’t that senior software engineer like the more carefully crafted code ?   He has probably never given how he writes code a second thought let alone a first thought and he has probably been writing code that way his entire career – never trying to figure-out why his code ever fails… but since he works with so many people he probably never gets an opportunity to see why his code might break and he can always blame code failures on something or someone else without ever having to take personal responsibility for his coding style.

Why does this major fortune 500 company have so many code defects to deal with ?

Take another look at the code I was directed to write and take another look at the code that would fail in a safe manner and then you decide which function would last longer when variables change or the business changes or the design changes.

I have worked with more than a few programmers who think, because they lack sufficient experience, that certain variables cannot change.  I have also worked with those who feel web servers never go down.

In my experience variables do change and code can fail unless one takes a bit of care to ensure the code being written is fail-safe.

Is performance a legitimate reason to write code that may fail at some point ?

NO !

If calling functions and performing Boolean Logic is the source or some kind of performance issue then by all means stay in bed and pull the covers over your head because there is no hope for you, if you feel like this would-be senior software engineer was the least bit right in what was said.

Modern JavaScript is quite capable of performing single instance function calls as well as simple Boolean Logic statements without the need to be the least bit concerned about performance assuming performance was the primary goal.

Consider the following chunk of code again:

Code Chunk #3

Here we have everything on a single line of code, looks more concise than Code Chunk #2 but Code Chunk #3 also handles all 3 points of failure that came from Code Chunk #1.  For all I know the guy who did not like Code Chunk #2 may have been thinking of Code Chunk #3 but I doubt it based on how he used his words about performance and brevity, etc, and I have not been seeing code that looks like Code Chunk #3 is the body of code I have been looking at for this company.  I have been seeing a lot of code that looks like Code Chunk #2 and I can easily understand why this company has been dealing with so many quality issues.

Also in all fairness, the senior software engineer who told me he did not like Code Chunk #2 has been dealing with a great number of code defects during the past 4 months and has probably always been doing this for this same company and he is probably not allowed to ever get any time to reflect on anything related to his coding style or how he might make improvements to his coding style – he always might feel offended if he felt his coding style could be improved since he has some rather strongly held feelings about what looks like good code to him.

The moral of this tale, if you choose to believe any of it is…  with a little time and some reflection you too can learn to write more robust code that will stand the test of time and more than likely you would be helping the company you work for to enjoy greater profits by reducing their software maintenance burden while boosting the acceptance of their software among their user community.

OR

You can just ignore everything that was said here and continue writing code the way you have always been doing because your code seems to run faster or you just love to look at code that seems more concise or whatever the reasons…  but if you worked for a company that had you on a treadmill fixing a ton of software defects you might someday learn how to write more robust code…   In a world where most people want to ignore global warming those same people might want to ignore what might be more robust code.

I choose to write more robust code whenever I can because it saves me time and money in the future and I get my projects done faster when I do this. Believe it or not !

What are “smart codes” ?

Once upon a time, not long ago, I worked for a certain manager at a company we shall not name here who was responsible for about 1 GB (980 MB really) of ColdFusion code for a legacy portal he was rather proud of.

The problem with all this code, since I was responsible for maintaining it, is that it was not at-all well maintained and so it should not have been a surprise that this portal system ceased working one day well before I had done anything to it.

After some examination as to why this code ceased working it became clear that none of the SQL Queries referenced fully qualified table names which means so long as this portal logged into SQL Server using a certain user name this portal work work otherwise it would not work.  I fixed this portal by recoding all those SQL Queries so they reference fully qualified table names.  Since there was 980 MB of code this task took about 3 days to complete the task of getting this portal back online.

This particular manager believed there was no need to write any “smart codes”; we do not need “smart” codes he used to tell me.  This is all fine and well but if you believe there is no need to write any “smart codes” and your prized portal that uses no “smart codes” fails because it has malformed SQL Statements then what could one say about the rest of that 980 MB of code ?!?

Those who cannot allow “smart codes” are far more likely to make some really bad decisions while directing those development efforts for which they have direct control than those who not only know how to write “smart codes” but would not have any problem doing so.

How “smart” can it be to think smart codes are a bad idea ?   Not too smart at-all !  It would be by-far smarter to allow those smart codes to be written so long as the result is the software continues to work even when the software is not exactly being used as it was originally designed to be used.

Sometimes certain managers can feel intimidated by those who know their craft so well that “smart codes” can be written but what this manager was really saying is that he felt so uncomfortable with the software development craft that he had to insist on codes he could easily understand with his limited understanding and this is nothing less than very sad and all effed-up to put it mildly.  Why this manager ever felt the need to get out of bed in the morning is completely beyond my understanding.  Why not let those who feel they can handle “smart codes” do so ?!?   Why not ?!?

I hire professionals all the time myself – let’s call them doctors and lawyers… I let the professionals I hire to do their work because I surely cannot do their jobs for them – I do not understand medicine as well as any of the doctors I have ever used over the years and they all knew more about medicine that I ever will, even though I try to be an informed patient.  Do I spend my time telling them not to use “smart” medicine ?!?  NO !  I want them using all the smart medicine they know so I have continue to enjoy good health in spite of myself and my own efforts to do the contrary, it seems.  Same thing goes for the Lawyers I have hired with some caveats – Lawyers are supposed to be sharks and one should always watch ones fingers when working with sharks.

If you cannot understand what your software engineers are doing then watch the end-result of the code they are working with but don’t tell them how to write their code – and make sure to hire only those you can trust – this is always good advice.

How can the work I am doing today as a programmer reduce the cost of development tomorrow and who really cares anyway ?!?

If the code I write today is less specific than I might be tempted to make it I can in-fact reduce the cost of my development efforts tomorrow, whenever that tomorrow arrives.

Just like when I am driving my car I am being careful not to crash into anyone or anything because…. wait for it… the cost of driving my car is actually reduced when I do this once tomorrow arrives.

Sadly however very few if any software engineers even know-how to reduce the cost of development and surely not when doing so means someone else gets to get their job done using less effort than they used – what ever happened to team work anyway ?!?

Specific solutions are more easily broken by future decisions…  this is a fact of life for professional software engineers.

Abstract solutions are less easy to break – this too is a fact that is just over the heads of just about every single software engineers currently writing code today.   I can count on one hand using my fingers the number of fellow software engineers who felt a more abstract solution was better than a more specific solution.

More specific solutions are easier to build – “yes” this goes without saying.

More abstract solutions may be less intuitive than the other kind however the more abstract the code can be made the more robust the whole system becomes.

The more specific a solution is the more brittle it is and the less likely that code will be when changes take place.

Why don’t we all place the same value on our ability to craft more abstract solutions ?   Why don’t companies seek to hire the more experienced professionals they can find ?   Why is empire-building so profitable to your average corporate weenie ?   And what is the meaning of life anyway ?!?

As for myself, I will continue to build code I know saves me time and effort tomorrow as I write that code today – the cost is negligible all the way around however the benefits are enormous all the way around.  Doing this allows me to build projects on a personal level your average corporate weenie would not even be able to imagine let alone ever get built unless 5 or more programmers were used…  Trust me when I say, I have worked on teams of 5 or more fellow programmers who got much less accomplished per unit of time than I would have thought reasonable based on my own individual experience… but who am I to say a company should not spend $250,000.00 just to get a drop-down menu on a web page when doing that might have taken me 2 hours one day… on the other hand, if I had millions to play with I might waste most of it by hiring 5 times the number of people I really need otherwise OR if I were simply not well informed as to what is reasonable for one person to accomplish I might hire 6 of them and happily pay more than would have been required otherwise.

Bottom line is, I am able to get more work done faster than others I have worked with and this remains a constant across the board.  This is not vanity or being boastful – this is simply a fact.  Engage me and find-out why… if you dare.

%d bloggers like this: