Economy of Scale: when big is a waste.

Some short musings. I was thinking about why larger organizations tend to be less ‘agile’ or ‘nimble’ than smaller organizations. Even though larger organizations are typically broken into smaller and smaller groups. After thinking about it the phrase administrative abstraction came to mind. Here’s a quick break down of what it means to me:

Larges orgs: Typically high in price expensive but a low wait time once work starts. Getting authority can take time due to authorization, setup, or negotiations.

Med orgs: Reasonably effective, not to many levels of authority and red tape to work through when changes are requesteed. However, you may have to wait in line behind other client projects before your desire is worked on.

Small orgs: Usually very dedicated and willing but not enough resources internally to complete task to level of expertise req. to complete task.

What do you think, am I missing anything here?

Hackathons…an honest opinion.

When taken as a hole a hackathon is a marketing, networking, and possibly hiring event. Engineers and developers of all levels attend with the award of getting to demo a cool / neat / fresh solution to (generally) an age old problem. Hackathon’s do not exemplify the planning, fitment, trial and error, depth of knowledge, or thoroughness of execution. If you want shake hands and rub elbows, defiantly attend. If you want to demonstrate your ability at a specific technology, attend. If you want to actually solve the problem, pass. If you want to win, read on.

To win a hackathon contest your team will need three main things to stand a chance. 1) Get a public speaker on your team. This person should spend the entire time planning, practicing, and refining the pitch/demo. You will have a very limited amount of time to convence 1 to dozens of NON-technical people why you (possible) solution is THE best. One chance, make it count. It MUST be the best anyone has seen. 2) Have a technical wow factor; the more it looks like magic the better. Voice commands, robotics, haptic feedback, AR, VR, machine learning, computer vision. Or any other ‘WOW’ factor. Simply making a web app  will not get you into the semi-finals. (For example; MongoDB + NodeJs + Bootstrap + Google Maps). And finally 3) if you have item 1 and 2 covered; then, and only then, should you attempt to solve the challenge.  The solution does not have to actually work, just look like it could. Your selling the idea, not the actual implimentation the majority of the time.

The hackathon/s I have attended where fun and defiantly an interesting experience. But I’m to old to survive on 3 hours a sleep day after day. Giving up entire weekends, sleeping on couches, eating take-out every meal, sitting in front of a screen for 18+ hours for days on end is not fun to me anymore. Sure I do software for a paycheck, I am not at the keys more than I need to be. Solving problems takes thinking, lots of thinking; planning, then execution. Hackathon flip this backwards and put the participants under pressure to perform.

TL;DR: Attend a hackathon at least once and see if it is your type of event. For me though; I am to old for programing benders anymore; the body just cant hang with the 20 somethings.

Is the argument of ‘application portability’ a valid one for containerization?

Preface: I am a huge supporter of containerized distributed applications. It give me all sorts of nerd good feelings.

One of the biggest arguments for containerization of applications is that the application becomes portable. It no longer cares what it is running on, nor where, or how many. Windows server running a Unix FORTRAN application? No problem! Windows app running on a CentOS host? Done it! And while these are cool and nerd-awesome configurations. How often does an application actually change root host environments? If an application was/is made with .NET it is to leverage the advantages .NET has over other options. If RAILS, its for the advantages, if PHP, again, for the advantages over other offerings. To move away from those advantages negates the reason for selecting the solution.

On a related note; are we not simply replacing one type of vendor lock for a lock at another layer of abstraction?

Another month, another set of continuing education courses.

A corner stone of the IT/Dev career field is this: ‘never stop learning’. I like to expand on it and include ‘When you stop learning, your start becoming worthless’. While some disagree with this it has served me well. As such last night my Udemy collection increased by another 8 courses. Mainly focused on AWS assoc. certification training but also a few container / CI / CD services.

Hoping to sit down for the exams before the end of the year; here’s hoping ^_^.

Sad day … Iron Yard Closing.

To me the whole coding school bootcamp has always seemed like land mind field waiting for a chain reaction detonation. That said The Iron Yard is one of the more well established and respectable institutions. and that makes is even more saddening when they announced recently they would be closing all campus locations. This action will obsessively cut off hundreds of thousands of field entering individuals from mentors, channels of community, new life opportunities, and much much more. I really hope another group / organization can grow from this unfortunate series of events to help continue to grow the development field.

 

RIP
The Iron Yard
2012 – 2017

Did a thing today, ‘nother new package.

New Package: Stripe + CommandBus + Yii2

I got tired of writing out the entire Stripe class requirements coupled with the need to trigger stripe events from different areas of the application  motivated me to create this package. It is by far NOT production ready but lays the ground work and ideas for the package. Take a look, leave a comment, contribute.

Also have another one in the works that combines Google Chrome, Codeception, headless browser testing, and replacing PhantomJs (since the maintainers are deprecating the project).