Working at GitHub, a Reading List
I’m really interested in how other people and companies work. I like reading about their workflows and processes and am always looking to optimize my own workflow. In the last few weeks it became clear to me that what we are doing here at QUOTE.fm is actually building a company from the ground up, we’re not longer just individuals doing their own thing. We are in the position to define how we want to work as a team. That’s a great opportunity and also a great responsibility. It means trying things and always improving them.
I just finished reading a series of articles about how GitHub works. While I found that we here at QUOTE.fm innately are working a lot like the guys from San Francisco, I also got new input how we can improve.
So I encourage you to take some time and read the following stories.
Use jsfiddle.net for problem solving
I can’t stress this enough, use jsfiddle.net.
It is very simple, but also very very good. If I have a question I often put together some lines with jsfiddle and share it on twitter to get help. So everybody can edit the fiddle and save a new version to share it again.
It’s perfect for sharing but it’s also very good for private use. When I’m stuck on a problem while coding QUOTE.fm I’m often so caught up in the context of the whole site that I just need to start fresh and separate the problem. jsfiddle is perfect to tackle just a single issue. So I often throw together only the needed code to just work very focused on that exact problem. And usually I can work out a solution which I can use for solving the original problem.
Sure you can do this locally with your code editor, but jsfiddle is much faster and again, you can easily share it if you need to. I also like to save my solution so I can come back whenever I need to look at it again. Here is an example of a problem I had and where jsfiddle helped me to get a fresh look at it.
jsfiddle is just an alpha version and is constantly getting better. I’m sure I haven’t even discovered everything there is now â€“ for example I just discovered keyboard shortcuts for saving, running the code, etc.
So next time you have a question, a problem or want to just try something very quick, use jsfiddle.
Workplace experiments: A month to yourself
This June will be a full month of free time to think, explore, mock up, prototype, whatever. People can go solo or put together a team â€“ itâ€™s entirely up to them. This is a month to unwind and create without the external pressures of other ongoing projects or expectations. Weâ€™re effectively taking a month off from non-essential scheduled/assigned work to see what we can do with no schedule/assignments whatsoever.
That’s so cool and I think it’ll work out great for them.
On the one hand more companies should do things like that, but on the other hand only a few are able to put down their day to day work for one month and still be reasonable profitable, I think.
Working as a team
Bastian Allgeier wrote an article for .net magazine saying, every designer should learn to code and every programmer should learn to design.
For an interface designer, handing over your designs to the developer means losing control of the creative process. Of course, you will be working together on the project and communicating back-and-forth, but it will never result in a creation that is all of your own. In other words, you will never be independent in your creativity.
Bastian is the creator of Zootool and kirby, the awesome file based CMS. He studied Design and then learned how to code. The reason for him to do everything was to be independent. He can do whatever he wants because he can do everything by himself. That certainly has value, but beeing a generalist also has some downsides.
At QUOTE.fm we work as a team of experts. Okay, we are fairly young and years away of being experts, but everybody has his core strength.
Marcel for example does all the design work and almost everyday we discuss his latest creations. He does the best design he can dream up without thinking too much about the other parts of the process. Then it is up to me to analyse if it’s possible to do. My standard answer is: „Everything is possible.“ And if I don’t know how to do it yet, I will figure it out. It is all about doing the best work possible, not the easiest. I can’t stand people who say that something is impossible without really trying first. In my experience everything is feasible, the question is how long does it take do find the solution and are you willing to go the long way instead of the easy one.
In my opinion it is much easier to achieve this if you work in a team with experts, who also know the basics of the other crafts, so that you can discuss every decision and motivate each other. That’s a very important part which you loose if you work alone.
I can see that not everybody is in the position to have a great team and that it is good if you can do a project on your own, but it is not the best possible way.
In the end it all comes down to loving your work and trying to build the best product no matter what.