I’ve been inadvertently living off of the progress made by the open source community for my entire career as a web developer. And while I haven’t given back nearly as much as I should, I have been spending a lot of time thinking about “what it all means”.
For me, when I have reflected on my most productive time spent working with any new technology or code base, it boils down to being directly proportionate to the degree to which that technology is open source.
I am so convinced of the effectiveness of open source solutions over closed technologies that I consciously seek out opportunities to introduce open source into my work as an end to itself. Switching to Linux as my main operating system for my personal work, as well as for some of my “day gig” work has also been eye opening.
It is a journey that reached a water mark this year, and has me resolving to give back as much as I have taken over the years.
Up front, this blog post would not exist without the amazing work and progress towards pushing the Front End Ops agenda by such trailblazers as Wesley Hales and Ryan Bridges, who gave a cool talk at the Velocity 2013 conference in Santa Clara, California. Of course there are countless awesome developers committing to the projects associated with this trend.
Once we have sorted out how we plan to manage our assets, only minifying and redeploying the essentials with each build, how can we baseline our progress? There’s a great tool called LoadreportJS (GitHub repo is here). Additionally SpeedreportJS gives us some additional visualization tools. Both of these JS options rely on PhantomJS (which gives us a headless WebKit instance, scriptable for automated client side web page testing).
When it comes down to it, these tools give us the opportunity to get a baseline on our specific web application, and that is an essential point. Each application is its own unique animal, and we need to establish that unique point of reference, rather than compare it to other reports or trying to establish some sort of generic target performance metric, which would be neither here nor there. So a concrete, individualized zero state and target end state needs to be established for each unique application. That is essential.
So that’s an interpretation of the break-neck pace of the evolving front-end ops role from here on the ground. I’m fascinated by the fast moving rate of progress in this space. I’ll be doing my honest best to integrate these learnings in an effort to merge ops tasks into my more traditional front end developer work-flow.
What would it mean for all of us to use an open stack, from top to bottom? Once we loose our paranoid grasp on straws made up of proprietary systems, what is left for us to hold? Would we float free for a moment, suddenly disoriented, then newly stable as we found our sure footing? Would we stand tall, knowing that the systems that we employed were not snares or traps? And then: as long as these questions are unanswered for a single one of us, how can any of us rest?
I haven’t spent too much time crowing about it to my friends, but earlier this Winter I purchased a laptop from System76.
I could go on and on about specs and performance, etc. etc. but suffice it to say that I bought the Pangolin Performance model with slightly more than standard RAM. The laptop has performed extremely well for my development tasks. I am continuing to run Ubuntu 12.10, and the OS has proved to be a pleasant environment to work in.
An unexpected side effect of the laptop and OS design has been a removal of clutter from my personal development workflow. My process is now more streamlined and focused. Thanks System76 and the Ubuntu OS community. You’ve won an avid enthusiast and supporter!
The best managers I have had do two things well: they remove impediments to a trusted developer’s understanding of the larger business purpose behind that developer’s task, and they, as proficient developers in their own right, approach solving problems in what seems to me to almost be a “refactoring” mindset. They look at what is confusing or misleading in the overall process and put plans in action to clarify and clean it up. They work with people as fluidly as they work with code. And they understand that just as clean code performs the best and is the most maintainable, clear communication with and among the developers in their constituency will lead to the greatest progress in the near and long term.
Overall, my initial impressions were mixed. I was very interested in parsing a new language with PegJS, mildly interested in code analysis tools, and lost interest when it came to fabricating a crude drum pad instrument. But whatever your pleasure or poison, hopefully the earnest appeal for community and improving the world through software development, and more importantly, by just being a passionate human, strikes a deep chord within. This is the first conference I’ve ever been to that affected me so deeply (and unexpectedly). And while it would be ridiculous to assume that this is unique to the JS crowd, they seem to have it. In spades.
As a (mostly) self-taught web dev with little formal college-level Computer Science education, it is easy to hold those who possess this specialized training in high regard. And as someone who relishes learning new and novel ways of solving common problems in the abstract, I value what I pick up along the way as I address bugs and recurring puzzles.
However, my interest wanes when it becomes apparent that a problem is being addressed from a Computer Science standpoint at the expense of Common Sense. Let’s solve problems in as straightforward a way as possible, based on the current known use-cases.
Computer Science and Common Sense: powerful allies.
I don’t think it’s a stretch to acknowledge that there are plenty of problems that humankind faces that just will not be solved by the Internet. Which then begs the question: what problems, if any, are worth solving? The Internet is a network. And not simply a network of “things” but a network that serves it’s higher purpose when facilitating the interconnectedness of people. To this end the humble blog, in all it’s varied forms, may be the most powerful and empowering use of this technology: it simply, and to a degree, effortlessly, enables the sharing of the most private thoughts, incisive criticism and cogent discourse. It may be that simplicity and straightforwardness are goals to strive for in web development as well as life. Maybe we are entering a phase where technical prowess will be superseded by the power to empathize and serve the human interest.
Are we on track for a future where the skills of a developer will become all but ubiquitous? Will there still be a place for product managers and UX designers unless they are not merely conversant in the tools of a developer, but proficient? Will fluency with code be a bare essential? Or, put another way, will we see a time come when no mouse is calling on others to bell the cat, but will have the courage and resolve to do the deed himself?