School killed Him. Work killed Him. I killed Him.

He realized, like all who are killed, too late of his impending doom. His second to last thought was that maybe if He had realized sooner that the things around Him were killing Him, He could have prevented it. His last thought was that He had begun being killed on his first day of school.

School – What a joke He thought. All of that time that He spent there, and what did it get Him? A personal sense of worth on somebody else’s scale. A thought process that began and ended with "what do others need me to do?" The more He thought about school, the more He realized that the first cut in his death by a thousand, was from school.

"The teachers only taught what us students needed to know for The Test" He thought. "What was on the test anyway? Basic reading comprehension and even more basic mathematics? How depressing it would have been to be one of the people that didn't pass."

A fateful smile crept appeared on Him as He put together a body and a face for this dark shadow that had been about Him all through school. "They were celebrating the mediocre", and a forlorn chuckle escaped his lips.

"They only wanted people just good enough to not need assistance in life, but not so good as to see through Their ruse."

"Well I saw through the ruse, but only in my last minutes" and the threadbare smile faded and the chuckle turned to silence.

He thought back to his "Critical Thinking" class that He was forced to take – It isn’t really critical thinking if you have to agree with the teacher in order to get credit.

He thought back to group projects – The other members of the group were lazy slobs, and yet He received poor marks on the project. "Surely the Real World is not like this" He remembers thinking when seeing his marks.

Work – The Real World.

"No", He thought, "the Real World was just as bleak as school had been." He had had what others would call a decent job. He had climbed all of the ladders, but no rung was what He was looking for. Every new rung that He passed, the same old thought occurred, "Someday I am going to leave this place and do My Own Thing." But there was always another rung, and always another reason to wait to do His Own Thing. He was paid to solve problems for The Company, but He could only give solutions that The Boss wanted to Hear – He could never give the correct solution. He thought back to his co-workers and thought that his lazy co-workers were the same people from his school that had passed through without significance; They were good enough at their jobs to not lose them, but not so good as to turn The Company’s boat away from where it was always Heading.

Me – I bear the most guilt in his death. I led the lamb to the slaughter. At first, I lead through innocence; At the end, I lead through apathy. It was my job to keep Him alive, and for most of his life, He only stayed alive through sheer dumb luck.

That one saving math teacher – that one fulfilling job – those are what kept Him alive.

I always knew deep down that one day He would become all of me or none of me. He had always been a part of me; Telling me that smart-ass remark to make, showing me that clever solution. I had just thought that everybody had a companion like this, but no, I was of a rare breed I guess. That part of me is gone now. Like any living thing, eventually it will lose some battle and be lost forever. Now I am just a drone to do what others tell me and not what I want. My Own Thing is now Their Thing.

Afterward

I wrote some time ago in an act of catharsis, and am just finally getting around to publishing it. I hesitated to share it originally for some now unknown reason – I share it now because it feels more right to share it than to keep it only for myself to read.

On the plane back from LibrePlanet 2014, I have tried to put together a debrief, but as I am running on about three hours of sleep, I am not sure how coherent these thoughts will end up being.

I always leave LibrePlanet feeling very inspired and ready to go forth and hack on even more. In retrospect, it is strange, and kind of sad maybe, that what I do for a day job is not this inspiring. I thoroughly enjoy what I do though, so maybe this phenomenon occurs only because LibrePlanet is especially inspiring.

Once again, LibrePlanet afforded me the opportunity to interact with people in the flesh that I usually only interact with via email or IRC. And of course, I also met lots of new people who are working on even cooler projects.

I am eagerly awaiting all the talks having their recordings posted so that I can watch the talks that I had to pass up in order to attend other talks (or give my own).

I am very grateful to the staff, volunteers, and attendees that made LibrePlanet a success, and I am looking forward to next year.

Just as a painter paints because he enjoys the act of applying brush to canvas in order to create a reality out of an abstract idea, I code because I enjoy the act of putting fingers to keyboard to make a reality out of an abstract idea. Painters don’t paint because it is incredibly profitable, and I don’t code for just a paycheck. The money that I make from coding ensures that I am able to practice the art of coding my own abstract ideas instead of someone else's.

A day job as a developer will never make me happy nor make me feel fulfilled; Only the ability to hack on my own projects can do that. For this reason and this reason alone, I view all development jobs as the same and compare on the sole criterion of how much they enable my outside hacking. David Cronenberg once said "The desire to be loved is really death when it comes to art." I think that the same sentiment applies to development; If I only code for what someone else wants, then I have died as a hacker and have lost that part of my being forever.

I am a hacker. I am an artist. I use electrons, pixels, and switches to transform the beauty of the baud into a physical reality for my own enjoyment. I derive pleasure from making bits cross wires and pixels blink on screens. I experience pain from tedium and monotony. I don’t write code – I write art.

Upon reflection, my dream workplace culture would have following properties, listed below in no particular order:

1. Employees are encouraged to use any system/config/setup that they want
2. Nobody ever has set work hours
3. Nobody ever has any set work place
4. Every employee is salaried
5. Any meeting lasting longer than 15 min must be scheduled at least a day in advance
6. If a meeting follows the pub/sub model, it should be an email instead of a meeting
7. All development happens in the open
8. Every employee has 1 day per week to work on anything that they want
9. Each employee must respond to at least one support case per week (if that many cases exist)
10. Every employee has the responsibility to be at least somewhat familiar with the company strategy and product roadmap(s) at at least a high level
11. Every employee has the right to be a part of the decision making process perternaing to the company/product vision/roadmap(s)
12. The only information that an employee is not privy to is their coworkers’ salaries

Explanations

Employees are encouraged to use any system/config/setup that they want

Here I mean that I want every employee to constantly be tweaking their work environment to make them "better" at their job – whatever that job may be. For developers, this culture property probably means that they are encouraged to use any text editor, web browser, development tool, or operating system that they so choose. With regard to non-developer employees, this point probably means that they are encouraged to use whatever email client, software, phone, etc. is going to make them better.

The main point is that I want all employees to be enabled to constantly evaluate how they are doing their job and try to optimize their performance for whatever metric makes sense based on their role.

Nobody ever has set work hours

What I mean here is that I recognize that people have different schedules and different times at which they are most productive. Personally, I am most productive from 05:00 – 11:00 and then from about 18:00 – 20:30; For other people, this schedule is when they are least productive. The main point is that I want employees to be able to work when they are going to be most productive and not feel like they must work from 09:00 to 17:00.

Nobody ever has any set work place

The point here is very similar to point 2 above – I recognize that there are times when working in solitude at home is going to make a person the most productive and there are times when working from a coffee shop is going to be the most beneficial. There are also times when being in an office next to your coworker is going to be the best place to really crank out some work. I want the company to recognize and encourage all employees to be proactive about choosing the place that is going to be the best for them to work in. Personally, I happen to love hacking on code sitting outside on the grass in the sunshine.

Every employee is salaried

I don’t ever want an employee to think, "it is 17:00, time to head home and quit thinking about this problem." nor do I ever want any employee to work longer just to make more money while being less efficient. I think that salaries encourage people to be productive however they personally can. Also, with wanting point 2 where no employee has set working hours, paying an hourly wage would require massive amounts of paperwork and process.

Any meeting lasting longer than 15 minutes must be scheduled at least a day in advance

This is partly a corollary of points 2 and 3, and partly a standalone point. With every employee working whenever and wherever they are going to be the most productive, meetings that require synchronicity must be scheduled in advance. Additionally, some people (myself included) like to run through a mental plan of how their next few days are going to go, and being knowledgeable of all the requirements on my time is essential for that process.

If a meeting follows the pub/sub model, it should be an email instead of a meeting

There is nothing worse than a meeting in which one person is just pumping information out to the rest of the attendees with no needed response. I call this the pub/sub meeting model – as in the publishing/subscribing model for syndication and event handling. These kinds of meeting are a huge drag on people’s attention, energy, focus, everything, and are better suited by the speaker sending the information in an email. Meetings are only necessary when discussion is required.

All development happens in the open

This point may only apply to developers and their ilk, but I think that it is very important that developers be allowed to see, and contribute to any code that the company uses. This allows (potentially) more eyes to review code, and it allows developers to take a brief diversion and work on something possibly entirely different than they normally would. The advantages to this are at least twofold; This helps prevent developers getting bored with their work, and it encourages developers to always be learning new things instead of having their skill set stagnate.

Every employee has 1 day per week to work on anything that they want

A corollary to point 7, is that every employee has 1 day per week in which they are encouraged to work on anything that they so desire. This side project could be related to their job, or it could be practicing basket weaving. The rationale for this point is the same as the rationale for point 7 – preventing boredom and skillset stagnation.

Each employee must respond to at least one support case per week (if that many cases exist)

I think that is important for every employee to realize what the end users’ pain points are in the products. Having this information readily available makes it easier for employees to make executive decisions and make the products more user-friendly. It is also always extremely eye-opening to see how exactly customers are using what you made. Often times it seems like customers always find a cool way to abuse the product into working in some unintended manner.

Every employee has the responsibility to be at least somewhat familiar with the company strategy and product roadmap(s) at at least a high level

This builds on point 9 above, if every employee is empowered to make the products better, they should know where the company has decided to make the product end up.

Every employee has the right to be a part of the decision making process pertaining to the company/product vision/roadmap(s)

Since employees are required to have a rough idea of the company vision and product roadmap(s), they should also have input into what those visions are. Employees also have firsthand knowledge of how customers are using, and how customers are abusing, the products because they are seeing support cases come in. This knowledge is information that is required in the product planning process.

The only information that an employee is not privy to is their coworkers’ salaries

Based on all the points above, employees are going to have a high degree of knowledge about the company. Employees are also going to be used to being able to improve any aspect of the company, which has a prerequisite of knowledge. That knowledge should be made available to all employees. It would be incredibly heartening to see real data on the company when things are going well and really eye-opening to see that same data in a downturn. That being so, the only information that an employee should be able to see is what their coworkers’ salaries are. While this information would be interesting, knowledge of it would create a heirarchy which might work to stop employees from being as proactive as they otherwise would be. Employees may start thinking, “that person makes more than me, so their input must be more valuable” which is false thinking and will lead to demoralization.

Drawbacks

There are probably some definite drawbacks to these points. I can see that some people might not see the value in paying employees to spend one day a week working on something that may have no direct benefit to the company. I can see how in a very large organization, point 11 might result in a "too many chiefs, not enough indians" kind of situation. I can see that points 2 and 3, under which no employee has set hours or location to work in, might result in inefficiencies.

I think that the first drawback of paid side project time is sufficiently addressed in the rationale for that point above. As for how to avoid the "too many chiefs, not enough indians" situation, I am not sure of a solution. Assuredly, not every employee is going to want to be a part of every decision-making process, so maybe this situation is self-fixing. As for employees who have no set work hours or place becoming lazy and inefficient, I think that the proper solution is to be clear from the onset that any employee who routinely fails to meet the expectations of them will be let go. This has the effect of ensuring that employees who can keep themselves on task, and are proactive about self-improvement remain and thrive, while those that cannot are not a drain on company resources.

Conclusion

When I had my wife proofread this, she asked me "So are you unhappy with where you work?". The answer to that is a resounding "no!". I rather enjoy my current job and the culture there has a majority of my points in it. Would I quit this current awesome job to work somewhere that has all of my points as part of its culture? The answer is that I don’t know, and it would require some thinking. When I have my own company someday, or am a very early employee at a company again, am I going to try and get these points to be part of the culture there? Of course I am going to.

I am of the firm belief that while I may get paid in exchange for slinging code around, it is always my responsibility to improve how I and my coworkers do that slinging.

Two weeks ago I attended PyOhio 2013 – It was freaking awesome! I had high hopes for PyOhio as the last conference that I attended was LibrePlanet (which was also fantastic), and PyOhio did not fail to deliver.

In addition to listening to some really cool talks, I got to give a (hopefully cool) talk on what I work on all day – Copy.com. The talks that were presented were on a wide array of Python-centric topics and ranged from “novice” to “expert” in subject matter. The people at PyOhio were just as interesting as the talks. I met one person from LightSide, who is doing text analysis on student’s papers. I met another person who is a developer on Firefox for Android and picked his brain on porting GNU Icecat to Android. There was another persom that I met who works for Canonical on one of their webapps – It was great to trade “war stories” and talk shop.

My talk on a Python FUSE layer for Copy.com went rather well, and for interested people, there is a video posted at PyVideo and YouTube.

I will definitely be going to PyOhio 2014, and will even try to come up with an exciting Python project to talk about.

Towards the end of March, I attended LibrePlanet 2013 in Boston, MA. This was a weekend conference put on by the Free Software Foundation that was all about free software and bringing together members of the various free software communities. It was a fantastic weekend! I attended a few talks, and a workshop/install party, and learned a bunch.

Thursday evening, I met some people for dinner that I had only ever know from IRC. Little did I realize that this was going to be the case all weekend!

Friday morning I explored Cambridge, Harvard’s campus, and MIT’s campus. Then after a quick lunch, I took the T downtown to work out of the Free Software Foundation’s office. While it was kind of strange to putz away on my day job work from a place that would frown on what I do for my day job, it went very well, and I met even more people in person that I had only known from IRC.

Friday evening there was a meet-and-greet at the FSF office, where once again, meeting IRC people in the flesh was the order of the day.

Saturday began the "actual" conference, and I walked to the Harvard Science Center with much enthusiasm. After a breakfast and some quick conversations, it was off to the talks and workshops!

One of the talks that I attended was on the recently passed MA Right-to-Repair law. The talk was generally about the free software that may (or may not be) in cars, and how recent legislation is driving more people towards free software.

Another talk that I attended was on IceCat and LibreJS. IceCat is a GNU project that is a web browser based off of Mozilla Firefox with all the Mozilla branded stripped out, and added privacy features. LibreJS is a Firefox/Icecat/Iceweasel plugin that allows users to avoid the “javascript trap” of running non-free javascript on their machines. These two projects are near and dear to me as I hack on them, but it was very nice to meet my collaborators in person.

I also attended a talk by Stefano Zacchiroli, the current Debian Project Leader, about what the Debian Project is doing to become a Free Software Foundation endorsed distro. This talk, and some of the discussions afterwards, were the catalyst that made me change from my beloved Arch GNU/Linux to Debian GNU/Linux on my main machines.

Then of course there were the Free Software Awards, preceeded by a talk from rms (Richard M. Stallman, Founder of the GNU Project and FSF). The talk was what I expected, and the awards were given to deserving projects.

I also went to the workshop/install party for Replicant and Coreboot. Replicant is an Android fork that has of the non-free parts taken out, as well as all the Google specific parts. The end result is a cell phone that runs on (mostly) free software. There are still some non-free firmware bits, but that is almost unavoidable. The second part of this install party pertained to Coreboot. Coreboot is a BIOS replacement that is entirely free software. While my machine is not able to run Coreboot, it was pretty cool to talk with one of the developers of Coreboot and learn more about how BIOS’s actually work.

In the end, LibrePlanet 2013 was a great experience. I learned a lot about various free software projects and free software in general. I will definitely be going back next year.

Last weekend I had the privilege of volunteering, along with about 60 other people, at Ann Arbor Give Camp. Essentially, a Give Camp is a weekend hackathon where non-profits with a technical need (website, analytics tool, donation tracking, etc.) that they do not have the budget for, get volunteer developers to fill that need with some awesomely cool project. The project that I worked on was updating the design of the website and implementing a membership directory for a contractor's association.

Give Camp is different from any other hackathon that I have ever been too. First, you aren’t building a project just because it has cool technical merit or because it might be a viable business. You are building some project because some do-good organization needs it to do more/better good works. Also, Give Camp is different in that you are building a technical project for a group that (probably) isn’t very technically savvy. This fact tested both my patience when teaching our non-profit representative how to use the new system, and my design skills. I was challenged to come up with simpler wording on administration options, a more intuitive layout, and a streamlined workflow for the most common use case.

Give Camp also got me out of my personal tech bubble. I was unaware that there where people who self-identified as “.NET Developers” – Based on the make-up of my group, they are orders of magnitude more plentiful than I thought! That same revelation also made me see that a person could in fact do serious development on a Windows machine. I guess that I knew that these things existed, I just never encounter them in my days as a web developer/embedded systems developer.

My weekend at Give Camp was an amazing experience. It felt good to do good, and I got out of my tech bubble. I would recommend that anybody in the Ann Arbor area volunteer at next year's Give Camp, and for those elsewhere, I would absolutely advocate that you look for a Give Camp near you.