IGNAZ Softwaremanufaktur

I did this small presentation at the Schmiede in Hallein/Austria. The Schmiede is a festival for people from all sorts of background creating art and other stuff together. 

I worked in a number of startups that failed. I finally put all the things together that went wrong in my previous startups so others can skip making the same mistakes as we did. 

Hope you like it.

(by Anton Pirker)

Git - A beginners Overview - with comments

I have written a small introduction to Git. This should help people starting to manage their code with Git (or moving from SVN or an other version control system to Git) If you can not read the text in this commented version, there is also a version containing only the presentation without comments. Check it our here: http://www.scribd.com/doc/84675694/Git-a-beginners-Overview

(by Anton Pirker)

I am not a human resources guy and have not hired a lot of people. But I am a freelance developer and I love my job so I know what is important and what is not.

The client I am working for needed an extra developer to get all the work done. So he assigned me to search for a great developer.

I wrote a job ad describing what was important to us. I was searching for a Django developer. A person that has a passion for writing beautiful code, has a "getting things done" attitude and knows our core technologies. I also gave an overview of the job they will have to do, so they get the feeling that they will indeed do an essential part. That their doing really matters to the system as a whole. I also requested them to send a CV and a "why i am the best for the job"-letter to our contact e-mail address.

Than I posted the job ad to mailing lists for developers that use our core technologies. I posted it also to Twitter, Facebook, Google+ and sent it to the hacker space in our town. I also asked ex coworkers and friends from university.
And after setting the bait, the waiting began.

I got three kinds of responses:

• The first were the guys that just sent a link to their website.
• The second were the guys that wrote a two sentence letter accompanied with a CV where they listed every technology they ever used or just heard someone talk about. 
• And there was the third kind – the ones that really wrote an actual letter why they like to develop software, how they work, what projects they have done and what they contributed.

You can forget about the first two. A person that is not able to write a letter why he is the right for the job is probably very sloppy in doing his work. And a person that lists a whole lot of technologies will do everything if you pay him, but will probably not be really good at one particular thing.

So send them a short email where you thank them for their application, but you found someone else. (This is important – at least to me. They are people too and need to plan their future. So just give them a short note and do not waste their time while waiting for your reply, not being sure about your answer.)

Ok, focus on the third group. Invite them to an interview. (By now you probably have your favorite candidate.)
In the interview you get to know your candidates. Focus on the following questions: Do they fit into the team? Do they have experience in the field you are searching someone for? Is he confident? (After the interview your favourites might have already changed. Maybe your former number one just looked good on paper.)

At the interview you should also tell them that they will have to do a coding test. Tell them about the process: You will send them two assignments via e-mail. After one hour they send you back their code. The candidates just need one hour more of uninterrupted time.

We did test assignments that where closely related to the work they will have to do in the job. Preparing a basic project setup, we also built in some little problems (e.g. unicode issues).
We also put “.git” directory into the barebone app. So they could earn some extra points if they would commit their changes to git.

When you get back the test code, a lot of things will become clearer – at least in our case. You will get a quite good feeling for how someone is programming. Is he sloppy? Does he document the code intensely? Does he use standards? How is his naming of variables? Does he write test code? And so on.

We had three really promising candidates: Tim, Jack and Michael

In our case Tim was our favorite candidate after the e-mails followed by Jack and Michael.
Tim simply had the best CV and had a lot of experience on the job.

After the interview Jack lead the race since he made a confident impression and seemed to have an opinion on quite every subject you would throw into his direction.
Followed ex equo by Michael and Tim. Tim was especially nervous and not very good in selling his strengths. Also being a little bit shy about his skills and clearly not overstating his experience.

Then, at the code test shy Tim blew us away. He did really clean and readable code. Almost a perfect 10. Michael did also a great job but not as perfect! The confident Jack sent us some really sloppy code – some stuff was just plain wrong and he only got half of the stuff done. Pretty disappointing – especially after the good and self-confident impression we had from the interview.

So after all this, we were pretty sure Tim and Michael would be perfect fits for the job. Jack was out. Imagine yourself who was our winner in the end.
But that’s not the point! Just going by the default hiring process we would have stopped after the interview and probably hired Jack and let go of our two finalists.

Sure, all this takes some time of preparation, but it is worth it. You just can not afford to employ B-Grade people if the success of your company depends on the software they are writing.
Just invest the time needed to complete this process. What is one day of preparation compared to (maybe) multiple months or years of co-working with the second or third best fit available.

(by Anton Pirker and Stephan Pötschner)

You want to make your developers happy and want them to give their best to write this awesome piece of software you want to launch? Here is a small list of stuff that make developers happy:

1 - A fast computer

Developers do not like to wait for their code to compile or for applications to start. So buy a really fast computer. Buy all the memory you can fit into the computer and also buy a big SSD. If a developer has to wait just a few seconds he/she will fire up a browser and will go to her news reader, Digg, Y-Combinators Hacker News, Tumblr or some other site and will spend the next ten to fifteen minutes looking at cats that look like Hitler instead of doing some actual work.

2 - Plenty of screen real estate

Developers need at least two monitors. One for their code and the other one for log files, skype, chat-window to chat with other developers and so on. Monitors are cheap so buy at least two of them.

3 - A lot of power outlets (not in picture)

Most of the developers love gadgets. So you need power outlets for: the main computer, the test mac, the old fileserver, the computer that is just there to try the newest and hippest linux distribution, the two monitors, the kvm, the usb hub, the charger for the laser pointer, chargers for at least three mobile phones or tablets. So you sould plan at least fifteen power outlets per developer.

4 - An overview on what has do be done

Most developers are passionate about their work. They love to write code. So it is essential that they know what they should be doing. If a developer has not an exact plan of what he/she will have to do the next few days it will happen, that he/she will code a feature, that was never planed but was fun to code. Having a feeling for all open tasks is vital to efficient progress. (We use SCRUM to manage our projects, which is the first project management system i have used that is actually working well. But this is another story)

5 - Silence

This is probably the most important thing a developer needs! If a developer is working on some code and is not distracted he/she will get into the flow, where everything around vanishes and the complete focus is on the problem to solve. If you distract the developer with a some random question it would take yourself just 2 minutes to figure out, the flow is gone. It will take about fifteen to twenty minutes for the developer to get back into the flow. This is just wasting time and money.

If you have the space and money, put every developer into his/her own office with a door that can be closed. Right now we have not enough place to have single offices, so we went with a much cheaper solution: Ear plugs! In our office everyone is in the same room. The designers, the developers, the sales and management guys. When a developer plugs in the ear plugs he must not be distracted. Imagine them as plugged into the Matrix and everyone (also the bosses) have to wait until they are back. Ok, if the Live System is not reachable you can distract the developer. But  everything else has to wait. It will not take longer than an hour before the developer will unplug himself to get another coffee/drink or just needs to relax for a few seconds. 

6 - Hardware for testing on other platforms

If you test your software on multiple platforms (if you code for the web this is probably the case) put this device on the desk of the developer: be it an old laptop running windows vista, be at the newest iPad you are aiming for. It does not need to be the fastest version/machine, but it needs to be in the developers reach. If you have just one test computer for everyone somewhere in the office the developer will be annoyed by standing up and going to this computer to test stuff. He or she will just assume that it is working. And you do not want that!

7 - KVM Switch

This is for controlling multiple computers with one mouse/keyboard/monitor. This is really handy. It avoids that you have a lot of mice and keyboards on your desk or have to plug and unplug stuff all the time. Also make sure you get a real KVM switch and not only those cable things, they are just useless.

8 - Something nice (optional)

Maybe some plants to make the place more cozy. The developer should feel comfortable like at home.

(by Anton Pirker)

Okay, this post may be opinionated, since the creator of Tekla – Michael Hartinger – is also a good friend and schnitzel gourmet (knowing Vienna's best schnitzel including an unbelievable accurrate ranking). Apart from having gained such exquisit and quite useful knowledge, he is also a gamer at heart adoring Shigeru Miyamoto and all his Nintendo all-time-classics.

Knowing that good games don't have to be overly complex he began developing Tekla in his spare time for the iPhone in 2010: the concept was easy and well known – lead a snake through multiple mazes without destroying yourself by crashing into your ever-growing body or the walls.

Porting to a touch screen device like the iPhone, adding some salt and new ideas to this popular concept from Nibbles/Snake/Anaconda/Worm/Chase/Blockade and there it is: multiple hours of fun, jumping and navigating through the ever increasing difficulty of the levels.

Just give it a try and be prepared for re-experiencing the fun you had in your parents basement playing Nibbles in your QBasic Interpreter.

Beware: There is also a multiplayer version in the queue for all of you iPad Users.

(by stephan pötschner)

Here a list of essential readings (books and blogs) about user experience design and usability. This list was collected at the Usability BarCamp Vienna 2011. So all the usability folks of vienna are recommending these books and website! 

The Books: (affiliate links)

• Steve Krug - Rocket Surgery Made Easy: The Do-it-yourself Guide to Finding and Fixing Usability Problems (Voices That Matter)
• Susan Weinschenk - 100 Things Every Designer Needs to Know About People: What Makes Them Tick? (Voices That Matter)
• Don Norman - The Design of Everyday Things
• Steve Krug - Don't Make Me Think!: A Common Sense Approach to Web Usability
• Torsten Stapelkamp - Interaction- und Interfacedesign: Web-, Game-, Produkt- und Servicedesign Usability und Interface als Corporate Identity (X.media.press)
• Alan Cooper - The Inmates Are Running the Asylum: Why High Tech Products Drive Us Crazy and How to Restore the Sanity (2nd Edition)
• Dan Saffer - Designing for Interaction: Creating Innovative Applications and Devices (Voices That Matter)
• Alan Cooper - About Face 3: The Essentials of Interaction Design
• Wilbert O. Galitz - The Essential Guide to User Interface Design: An Introduction to GUI Design Principles and Techniques (Coursesmart)

Websites and Blogs:

• Hongkiat - http://www.hongkiat.com/
• Wireframe Wednesday - http://www.wireframewednesday.com/
• Web Design Ledger - http://webdesignledger.com/
• Modny73 - http://modny73.com/
• Signal vs Noise - http://37signals.com/svn
• Creaffective - http://www.creaffective.de/
• Boxes & Arrows - http://www.boxesandarrows.com/

Picture by the Horst Gutmann (@zerok)

We just came back from DjangoCon, which took place in the lovely city of Amsterdam. It was my first DjangoCon, Stephan has already been at a DjangoCon in Prague 2009.

It was really great: I have visited a few conferences (as speaker and listener) in my life, but this one was really outstandingly good. It had only one track of talks, so you could see all the talks without missing anything. That was the first great thing about the conference - the whole event was run very smoothly in general. Even the music in the breaks mirrored this fact by being pleasant, relaxing and being just fun to listen.

The other great thing was, that there were no talks, that were actually just advertising for the speakers company, start-up or project. All the talks focused on a problem and described how the managed to solve the problem. So we heard a lot about scaling, new interesting ways on how to use django, other stuff that are vital for growing start-ups or just some lightning talk on doing good.

Andy McKay (@andymckay) from Mozilla talked about how they are serving 500+ billion (!) api requests a day with a lot of Django. Jesper Noehr (@jespern) from BitBucket talked about how their infrastructure scales automatically to meet high traffic periods. Idan Gazit (@idangazit) gave an overview about how he is designing websites for various screen resolutions and devices (i.e. showing some real world examples of the hip term "Responsive Design"). Zack Voase (@zacharyvoase), who seems to be a very talented newcomer, boosted his github follower counter from a handful of people to about 70 by giving a great talk about writing resource oriented apps in django. He also did a lightning talk about his django-qmixins project, which judging by his code and documenation, seems very well documented and mature. Steve Holden (@holdenweb) talked about how to make the world a little better with almost no afford. 

For write ups of the talks visit http://reinout.vanrees.org/weblog/tags/djangocon.html and have a look at everything betweeen 2011-06-06 and 2011-06-08.

The other great thing about DjangoCon were the people. Very bright and open-minded people. It was great to hear some of their war stories in the breaks between the talks or when going out at night.

Most of them with a lot of experience in terms of large scale applications. So I heard about problems, I surely will encounter someday and also learned about ways on how to solve those issues. That's almost priceless. But only mentioning our geeky discussions would not hold up to the great nights/evenings we had in amsterdam: While the evening grew older, the discussions shifted to being more philosophical or wildly discussing some real world problems, exchanging literature or movie tips and so on. You probably might not expect that when going out with a bunch of nerds most of them knowing for just a day, would you?

It was also the first bigger open source conference I attended. And the special thing about DjangoCon is, that after the conference it possible to attend another two days with sprints. The attendees gather with everyone who wants to join (the sprints are for free) and work on Django itself or whichever project one is willing to support. So, users (including some the core developers) and newbies interested in contributing have a great way to start working on Django. Developing some feature they are missing, fixing some bugs, improving the documentation and so on. This year I did not sign up for the sprints, because I did not yet know the concept and did not feel as if I would be a great fit comparing to all those core developers: But by now I pretty much wished I had decided otherwise, since everybody should be able to contribute easily in some way. There should be no excuse and I am sure I missed a lot of great fun.

For one more sidenote: We also had free bicycles during our stay in amsterdam, sponsored by I amsterdam. So we could cruise through the city on our 'own' bikes. Awesome!

All in all, those last three days were just great and inspiring. See you next year in Zürich!

(by anton pirker)

While evaluating video encoding services for our current project, i checked out Zencoder. I tried the API with a demo account and had some security considerations. So i went to the Zencoder website and wanted to get some support. I did not find a solution to my problem in the documentation so i tried the support chat. Its done with Campfire. All i had to do was to enter my name and click "Sign in". I landed in a chat room with three zencoder employees. One of them greeted me right a away and asked how he could help me. I explained my Problem, he told me about a API feature i have missed in the API documentation. After a few minutes we solved the problem together. 

This was just an amazing experience. I was no customer of Zencoder at this point and it was so easy to sign in (no registration, email verification, entering of passwords or stuff like this) to a chat with people that can help you with technical questions. Now our client is a satisfied client of zencoder. Really great customer service.

(by Anton Pirker)