As part of NASA’s Parker Solar Probe, NASA is taking names that will be placed on a micro-chip and carried with the prove into close orbit of the sun! It’ll be a hot ride and a historic mission. Join the ride in name!
Found out yesterday was the 25th anniversary of the pilot movie. Am I getting old or what? (the answer is no, just iterating the property counter). Here is a link the watch the trend setting that is Babylon 5.
The saying ‘people don’t leave jobs, they leave their boss’ has been around for years. Herein Christie Lindor goes one step further and focuses on how organizations fail there employees. Remember, being employed at an organization is a two way deal. You offer your time , effort, and skill in exchange for monetary compensation. As long as the organization needs those things from you the organization continues to compensate. But what happens when the organization fails to delivery the non-tangible requirements?
I’ll be out of communication starting Friday till about the 5th of July. Taking a much needed vacation. Might be able to put in some time on a library or two while flying; but for the most part. I’ll be comms off.
(Preface: I am a full supporter of CLI tools, UI tools are nice but should not be depended on for day-to-day workflow).
Came across this interesting UI tool from NomadPHP‘s weekly mailer. ComposerCat. It visually displays the contents of Composers composer.json and installed packaged. It’s in beta but looks to do everything it says on the tin. Check it out.
Anyone who has sat through the process managing a project know, whole heartedly as a fact, no matter how much something is planned and scheduled something else will always go wrong. Believing this as fact one should never, ever, plan a time line or effort estimation based around everything working as planned. Planned and working are so far removed from each other the relationship is vague at best. No matter how many times we build the same CRUD application or data pipeline, or CI/CD process; always leave yourself some buffer time to correct unforeseen issues.
As a general guideline the less I know about a requested change the higher my effort estimation; almost geometrically. As an example:
80 hours to write a single data object CRUD UI
40 hours to write a single data object CRUD UI with defined fields & validation
20 hours to write a single data object CRUD UI with defined fields, validation, and user story documentation
8 hours to write a single data object CRUD UI with defined fields, validation, user story documentation, and visual mock ups of the expected UX
Now at some point I hit a floor where effectiveness just simply keep up with the continued reduction in effort. But at that low of an effort estimate we are basically wizards doing magic as far as non code people are concerned.
Some people will responded with ‘but estimates that high scare away clients’; This is very true and factual. However, my response is this: do you really want to work with a client who has not clear answer or concepts of what the results of the effort should be? Think `moving goal posts` but not having a goal post to begin with.
TL;DR: Always buffer your estimates, even if you know everything that needs to be done.
Every year my employer has a holiday party. This past year I rendered out all the projects we had worked on and put them in a loop on the big screen. The video renderer we used is called gource. Here is the gourcing of the current project.
Edit: So youtube is being…well Youtube and keeps deleting the video. Guess I’ll try again later :S. Still have it here so maybe twitch or something else.