In the year 2004 I was working in a development team and one guy suggested to use chat. I didn’t see the advantage to chat with other team mates next door. I could stand up and talk to them directly or pick up the phone. The chat client looked so ugly, I didn’t get notified on new messages, couldn’t see the history and so on. 2011 I joined Atlassian and they were using chat heavily. I must say, my opinion about chat has changed dramatically in the last 2 years. I think every organization should add chat to their communication tools to get rid of the email flood and be better informed what’s going on.
Here are my 10 reasons why I love chat:
1. Real time conversations
Emails are bad for conversations. Chat’s are designed for that. Asking a question, discussing a topic or just a group question: You normally get an answer instantly.
2. Team chat rooms
We have chat rooms for everything: Product development, product design, it administration, football, you name it. Chat rooms helps teams to discuss a topic or connects you with experts of specific topics.
3. Expert chat rooms
Do you know who to call in IT if you need access to a specific server? What was the IT guys name and is he maybe on vacation? A ticket system is too slow. We have expert chat rooms where IT experts or product experts hang around. It’s very easy to raise a question and get the answer within seconds with chat.
4. Real time development information
…at one place: build failures, deployments on the test server, new pull request: It’s our real time notification center for our code. When a build fails a developer can answer through the same channel that he’s looking into it. Our marketing has even connected our chat to Confluence and see edits of pages in a specific space.
5. Documented conversations
Our chat records every message. Even when I was not online I can look up what the team has been discussed. I also go back to conversations if I know that someone shared a link or a file with me that I can’t remember anymore.
6. Remote team discussions
I work remotely. I can’t imagine how I would share the link of our daily video conference, an update of a new presentation or just my actual experience at a dev conference with the rest of the team. No matter if I sit at home or being on the road: It’s my instant and always available connection to my team!
7. See who’s there
A green bubble next to my team mates name tells me if he/she is currently online and I can expect an answer immediately. When the person is not available I decide to write an email (yes, we also do that sometimes) or I write him/her anyway (see reason 8).
8. Offline notifications
When I’m offline or not at my desk for some time (yes, that happens) and someone writes directly to me or @mentions me in a room, I got a notification on my mobile and additionally an email. This way people avoid writing an email directly and I would answer through chat when I’m getting online again.
Never underestimate that: It’s hard to express emotions through text. In modern chat tools you have the possibilities to use emoticons, little pictures to show your emotions. If you’re surprised, just add (boom), which will look like (If you use HipChat here’s a list of all emoticons).
Bots are a great way to find all kind of informations: Which product version runs on our test server, when was the last deployment or ask if the current build on the master branch is green. Just ask the bot!
Chats can replace emails for a lot of situations, helps remote teams to grow together, can keep information in one place and act as a notification center… but it can’t beat face to face conversations and meeting people in person.
BTW: We use and love HipChat at Atlassian!
After more than 2.5 years working as an evangelist for Atlassian it’s time to look back on why the job rocks but also about the shadow sides. I guess every company have slightly different expectations when they hire for the evangelist role. At Atlassian we want raise awareness for our products and the company in general. We are creating products to help everybody that is involved in the software development process to work happily together. An ambassador at Atlassian has a strong development background and is not shy to talk to developers or jump on stage and talk about development in general. So it’s natural that a developer should fill that role.
My job is awesome
Speaking to developer
When I started I was a normal Java developer nobody knew. I started with going to conferences, was accepted to do some talks, met some other speaker, got invited to do some presentations and then got asked to do some keynotes! I really enjoy staying on stage and the more you do it, the less nervous you get. I say less, because I’m still nervous even speaking in front of a 10-20 people. I love putting ideas in peoples heads where they can grow. If I just can help 2-3 people start thinking more about improving their software development I’m a happy evangelist.
The community is great and people that I was looking up to when being a normal developer are now my friends. This job has open the gates for me to exchange ideas with thought leaders of this industry and believe me: They are also just humans ;)
Being an evangelist involves a lot of travelling in my case it’s about 30%. You hang around on airports, train stations and hotel rooms. Sometimes my travel schedule is so tight that I don’t see anything from the great places you’re speaking. Sometimes I just have to force myself to take a later plane and walk around the city I’m visiting. I’ve seen great places in the last year like Moscow, Kiev (before the situation escalated), Sydney, San Francisco, Atlanta and many more. A great thing is also that I meet Atlassian’s everywhere. We have people from local offices or that work remote in that region staffing a booth, so they can talk to the local customers and learn how our products got used in the field. It’s great to catch up with so many different colleagues.
I got the privilege to decide for myself what I want to speak about, what article I would like to write or new ideas for t-shirts that we should create for trade shows. It’s a very creative job where you have to come up with new ideas and new concepts all the time. What will developer like to hear, what is currently hot in software development, what is Atlassian doing? It’s so great if a create stuff in my home office in my little town in Germany and than the marketing in San Francisco want to reuse it for their global campaigns. This is also what this job is about: I’m the guy on the ground, I talk to many customers, I talk to thought leaders, I talk to developers. From all this information I can maybe create a more appealing angle of the story we want to tell our customers.
And if I think it’s time for me to get my hands dirty I’ll start coding for a while, not creating a product but just to do some small things improving my day to day work.
My job sucks sometimes
When working for a while at home I’m starting to miss colleagues. People that I can talk to each day. HipChat video can help but it’s not the same than meeting them in person. We’re trying to do team meetings at least 3-4 times a year in Amsterdam and San Francisco. The switch to not creating a sustainable software that people use each day was kind of hard for me. I now got used that marketing is a much faster business and collateral you created last month is old stuff and not used anymore. Also traveling makes me feel lonely sometimes. Sitting on an airport or in a hotel room, just myself, my iPhone and my MacBook.
Most of the people I’m collaborating with are sitting in San Francisco. We’re trying to coordinate our meetings that they happen early morning in San Francisco / early evening in Germany. So it’s sometimes not easy to meet friends in pubs, bringing my daughter to bed or taking my wife out to the movies, but it gives me on the other hand the opportunity to bring my daughter to the football training in the afternoon or pick her up from school for going swimming with her.
In the end I must say that I have the best job in the world. You have to be passionate about your products, your culture and the community you engage with. This makes me jump up each day in the morning. I’m looking forward to open the eyes of people to see that they don’t have to suck in software development and that they can be happy developers by changing the way they think about this profession. I’m so pumped to tell people that we have an amazing job: We can be creative, we’re helping people to be more effective and we work with cool stuff. You just have to realize that this industry is dynamic and it changes fast and so do we as developers need to change constantly.
Help me not feeling so lonely!
We’re looking for a team mate for me in France and the UK! Do you want to hang around with me in old hotel bars, spend the night in front of a screen doing a video conference call with people in San Francisco, or just pissing in your pants before going on stage at a developer conference? Sounds great? JOIN US!
“Code Reviews Are More Important Than TDD”
Dr. Venkat Subramaniam
Don’t get me wrong: Test Driven Development is great and it helps with a lot of things: Good quality, maintainable functionality, repeatable tests and much more. We did a survey at conferences that showed us that around 70% of all developer teams are practicing some kind of TDD but just 30% are doing regularly code reviews. Why is that? Here are some explanations why test automation is so much more common:
- It’s automated: Developers love to automate things. You can use a fancy build server and show that your code is running.
- It’s an easy to follow process: You write tests, you write the code, you run the tests. Easy to follow for each individual programmer.
- You do it on your own: There are no dependencies: Developer don’t have to wait for other developers to write tests, no social interaction is needed, the machine tells you if your code works or not.
The benefits of Test Driven Development are obvious, but here is why I think code reviews are more important:
- Better code quality: Reviewing the code by a team member can maybe not catch all functional bugs but it can catch obvious mistakes, correct bad variable, method and class naming and it improves the readability of the code (and we all know that we read code way more often than we write it).
- Learning: When reviewing code developer can learn from each other to write better code. Even intern can give senior devs a new perspective. This is also recommended practice for book writers: Read! But it also helps to understand the whole code base and not only the parts you are normally working with. You will review code from other parts of the system that you maybe were afraid to touch yet.
- Feeling better: Having another developer looking over your code before it goes into production can make you feel better. You don’t feel that you’re the only one responsible for a potential bug. There are others that haven’t seen it either!
Code Reviews with less meetings & better tools
So what’s the problem with code reviews? Why are not all teams doing them? First we should all agree that the time reviewing code is well spend! Some teams practicing a meeting every week to look at the code written the last 5 days or at a special feature. These can be a painful sessions for various reasons.
Make reviews less painful with tools.
When we discuss code in front of the whole team it can be hard for the author: Everybody is staring at his code and give comments. I’m not saying that it can’t work, but here we have the same social problems as we see with Pair Programming (and there’s just one guy looking at your code). I’ve seen people not showing up or coming with stomach problems to work because his/her code was on the schedule for the code review meeting that day.
A tool like Gerrit, GitHub, Bitbucket, Stash or Crucible can help because the author has more time to about the feedback and don’t feel like going into defense mode right away. In code review tools authors can invite other developers to participate in the online review. You see the code changes and add comments to the code. Developers with strong opinions won’t take over the review in tools that easily and others that may be a bit more shy have a lower barrier to participate in the review. But the same rules apply also for online reviews: Be gentle!
Make the review part of your process.
Don’t make code reviews an end-of-the-project event. Reviews can get long and boring. Keep them small. For people that already uses Git with feature branches this one is easy: If you want to merge changes back to the main branch you can create a Pull Request. Git tools like Bitbucket, Github or Stash have a visual interface to make comments. No change will touch the main branch without a review (if you want). Just make it a natural part of your process: If you have a change, it needs to be reviewed. Keep changes small so people are not afraid of reviews. A task is not done if the connected code review is still open.
Some tools also offer the ability to see the code changes in context. What’s the problem these changes should solve? Most code review tools let you connect to an issue tracker to be able to jump from the review directly to the issue.
If you still prefer review meetings do them regularly, so people get used to them. I think once a day would be best but at least two days a week. Never cancel the meeting because of too much work and try to review every change. If you can’t run through all changes split the group and rotate the group members.
Review code when it fits into your schedule.
That’s a problem with another meeting on our schedule: They never fit into our personal flow. If you do code reviews in tools you can do them whenever you got time: In between programming tasks, first thing in the morning or after the lunch break; independent from team mates and their schedule. Also: Don’t expect every reviewer to finish review your code. Someone will always not make it within one or two days or gets sick. Have a rule that you invite maybe 4 people and mark the review as finished when 2 people have approved the review. Just make sure that it’s not always the same people that are not reviewing the code.
Products these days are complex. If you think about how many people are involved to gather requirements, to discuss priorities, to write the software, maybe create hardware, to test each feature, to come up with a great design and to operate or distribute the products… not talking about marketing, finance & controlling here… Building great things is a team effort nowadays and communication is the key for success:
40% of creative teams productivity is directly explained by the amount of communication they have with others to discover, gather, and internalize information. [source]
How does information flow? Another statistic tells us that 70% of the information exchange is driven by the team lead and only 30% inside the team. The boss is a bottleneck: Information should flow freely inside the team. How can we change this situation and foster more collaboration inside and in between teams? Here are my thoughts for a collaboration revolution:
Problem: Physical isolation
A lot of workspaces are not designed for collaboration: A hallway with some doors left and right… How should information flow here? Open space offices foster collaboration. You can see who is there and start a direct conversation. Putting up open workspaces with couches, arm chairs or bean bags are great to work somewhere else but at your desk and have spontaneous discussions. When I’m in the Atlassian office in San Francisco I use these places to show that I’m not working on a very intense task that need all my concentration but be ready to be disturbed. On the other hand you should have mechanisms to show people that you don’t want to be disturbed because it will destroy your current flow of work. Some teams are indicating that by using headphones, even though they’re not necessarily listen to music or having a dedicated person on the team that is answering questions for the whole team (doing kind of support).
There is also a need not to isolate specialist. We know that cross functional teams are a great idea. Having a designer in the team when working on the new user interface is making decisions fast and understandable.
Problem: Communication barriers
Three communication barriers are making communication hard: Places, people and timing.
Places: It’s hard to get the right information when you work in a remote team, in a coffee bar or at home. But if you want great people, you probably won’t find them in your town and it’s hard to move them because the competition are already offer them working remotely (do you hear me Marissa Mayer?).
People: Employees keeping information on their hard disks, in Emails or in their own heads. Information are exchanged on hallways not accessible for all employees.
Timing: Meetings are a killer for individual productivity. They have to fit in everybody’s schedule. We also don’t work synchronized anymore! When someone is doing a coffee break another one just works on a great idea she just had at the same time.
We use our collaboration platform Confluence for tearing down the communication barriers. We once had a post on Confluence where our support expressed their feelings how unhappy they are with the work load and conditions. Independent of place, role and time zone other employees from Atlassian were commenting on that post adding arguments and trying to find solutions. After one week we put together a program for better work conditions in our support. We wouldn’t have accomplished the same results by inviting stakeholders to a local meeting.
Also chat is helping a lot when hitting a timing or place barrier. One team can start a conversation in a chat room during day time on this side of the globe and another team on the other side can join the conversation 12 hours later during their day time.
Problem: Foggy goals
If goals are not clear, how can we work as a team? I’ve been working with yearly goals that were obsolete after 3 month. But there was no mechanism to redefine those. Also I was missing a frequent check if I’m on a good way reaching my goals or on changing tactics how to reach those . I’m now doing a bi-weekly check on my 3 month goals that reflects our yearly team goals. Goals can be changed easily if the company focus changes.
Goals should also be transparent. What’s the reason that I don’t have the possibility to find out the goals of other team mates and other departments? It’s so important to align your goals to those other teams have.
Problem: Impersonal environments
Definitely the most important part of the collaboration revolution. If we have a good personal relationship to our team mates we know our strength and weaknesses and how to effectively get the work done! But more important: If you have friends at work it’s so much more fun. So what can we do? First have a good onboarding system. At Atlassian everybody needs to write an introduction blog post in their first week. People can make comments on it and learn some personal things about the new employee.
When your organization is growing it’s hard to know everybody. Hubspot is trying to solve this problem with an electronic wallboard in the hallway, showing faces of people and their name. Watch the video and grab the source code.
A few weeks ago I did a presentation on this topic. Here are the slides and a video on German.
The last 48 hours people were tweeting their tech horror stories in five words. This really made my day… but the scariest thing is: I’ve heard most of this quotes in real life! These are my Top 20 tweets:
My nephew creates web sites #fivewordtechhorrors
— Jason Bock (@jasonbock) December 11, 2013
“Who wrote this?… Oh. Me.” #FiveWordTechHorrors
— Liz Keogh (@lunivore) December 11, 2013
Yup, We Need Another Meeting #FiveWordTechHorrors
— Dion Almaer (@dalmaer) December 11, 2013
Weird. That worked in staging. #fivewordtechhorrors
— beerops (@beerops) December 11, 2013
It is only test code. #FiveWordTechHorrors
— Martin Thompson (@mjpt777) December 11, 2013
We are switching to PHP #FiveWordTechHorrors
— Viktor Klang (@viktorklang) December 11, 2013
“It works on my machine” #FiveWordTechHorrors
— Johanna Rothman (@johannarothman) December 11, 2013
“It’s too complicated to test.” #FiveWordTechHorrors
— Andy Hunt (@PragmaticAndy) December 11, 2013
We have to support IE6 #FiveWordTechHorrors
— Adam Yuret (@AdamYuret) December 11, 2013
Oracle has acquired Sun Microsystems #FiveWordTechHorrors
— Steve M (@shmick) December 11, 2013
The coffee machine is broken #FiveWordTechHorrors
— Arnaud Héritier (@aheritier) December 11, 2013
We’re going to use SharePoint. #FiveWordTechHorrors
— Simon Brown (@simonbrown) December 11, 2013
We need a Devops team #FiveWordTechHorrors
— Gareth Rushgrove (@garethr) December 11, 2013
— Andres Almiray (@aalmiray) December 11, 2013
It can't be tested yet #FiveWordTechHorrors
— Adam Yuret (@AdamYuret) December 11, 2013
Let’s update the stored procedure #FiveWordTechHorrors
— Sam Newman (@samnewman) December 11, 2013
Fixed it with global variables #FiveWordTechHorrors
— Seriouspony (@seriouspony) December 11, 2013
95% done, you finish it. #FiveWordTechHorrors
— George Dinwiddie (@gdinwiddie) December 11, 2013
We can add security later. #fivewordtechhorrors
— James Turnbull (@kartar) December 11, 2013
We wrote our own encryption. #fivewordtechhorrors
— J Wynia (@jwynia) December 11, 2013
“The original developer left us.” #FiveWordTechHorrors
— Lou Acresti (@louroboros) December 10, 2013
git push -f origin master #fivewordtechhorrors
— Jonathan Nicholson (@jonathanichlson) December 9, 2013
I guess every company wants to have productive and efficient employees that comes up with bright ideas and can execute, track and deliver them. This employee should smile all the time, doesn’t need a lot of attention and works always for the company goals. This is a nice wish, but in reality we need to do more to make sure that every individual developer gets freedom, runs in the right direction and is happy in what he’s doing. These are just 6 random things that will boost the performance of knowledge workers like programmers:
1. Set monthly goals & check frequently
I never understood the thing about annual goals. 2 month after I agreed with my boss on them some were already obsolete and didn’t make sense anymore. Things change too fast nowadays and annual specific goals makes us inflexible. Sure, we should have bigger goals and track the way that leads to them by agreeing on short term goals. I can concentrate better on a goal when it’s smaller and the due date is closer. It’s like running a year long sprint in Scrum. Doesn’t make sense! But: Track also your long running goals (like Epics in Scrum).
Short running goals lead actually to frequent checks with your boss or even better: with your team. You should meet weekly or bi-weekly, discuss the current state of your goals and update them. It worked for some teams to define team goals and personal goals (1:1 with your boss). Try to avoid mixing those.
2. Establish short positive feedback loops
If someone did a great job, you should have an easy mechanism to appreciate that publicly. That way people think feedback isn’t something awkward. We at Atlassian can give Kudos to other team mates just by raising a ticket in JIRA. The talent department sends a small gift with a card to the receiver of the Kudos. Everybody at Atlassian can start this, so it’s very lean and effective.
3. Freedom for developer
All knowledge worker know that innovation doesn’t happen between 9am to 5pm. Give people freedom to work wherever and whenever they feel motivated and productive. Give them the tools they need. Give them time to work on their innovations. At Atlassian we have tools like 20% time and innovation weeks. A special time where our developers are not working for planned features but on own innovations that improves our products or tools that makes us more productive. It motivates the developer to work on their own ideas and show them later to their team mates and maybe integrate them in the core products. There are lot’s of examples at Atlassian where projects from 20% time made it in the product… but also some that didn’t.
4. Don’t overlook the small things
Talking about the performance of developers: It’s not always the smartest to work on a big new feature. There are so many overlooked ‘low hanging’ fruits in most products that will improve the software with less effort. My collogue Benjamin Humphrey has written an excellent blog post about this. But I want to touch on the human side for this one: If the developer fixes two of those small improvements each Sprint the satisfaction level will raise. He will get fast (and hopefully positive) feedback for the small change.
Let people know what the big company goal really is. Let them know how good or bad sales are performing. Don’t treat devs like small children and hide things from them. It’s so demotivating and costs so much energy to hear and discuss rumours on the hallway or just don’t understand the overall goal. Give people an opportunity to ask questions (not just in big CEO announcement in front of 500 people). At Atlassian our founders are giving us regular updates about goals and performance in a blog post. We can comment on that and ask if we don’t understand a new goal. It’s important that everybody in your organization is on the same page with the companies vision.
6. Forget about specialists
I’ve been working for a company that was hiring specialists. I never understood why. Yes, of course we can all do special things in the team: Someone speaks fluently SQL, the other one is good in presenting and another guy is good in design. That shouldn’t stop us to try out other things. The specialist thing is getting weird when people don’t feel responsible for other peoples specialism. I’ve argued with some people in my career that didn’t feel responsible to do support or getting the requirements from the customer, just because it was someones else’s responsibility. Here is what’s really important:
“Go build awesome shit”
Mike Cannon Brookes (Atlassian Founder)
No more and no less!
Ideas drive our businesses. We all know that it’s important for our products to fill them with innovation so the users love to use them and we differentiate us from our competitors. But we as knowledge workers also have some small ideas. How often did it happen to me, that I was thinking hard about a solution for a problem at work, went home and had the answer somewhere between leaving my desk and entering the office the next morning.
So let’s face it:
You can’t plan for really good ideas
Where ideas happen
I’ve just been on vacation for a few weeks. Before that I had so much work stuff in my head that I couldn’t focus on new blog posts… But just by sitting at the pool for a few hours opened my mind and I had lot’s of ideas for new posts or talks. I think everybody has experienced this kind of innovation boost. I’ve spoken to a lot of people and this are my TOP 3 places for innovation:
Under the shower
I don’t know what it is? But all people I was talking to agreed with this one.
In the gym
I use to listen to technical podcasts or watching presentation while running on the treadmill. My mind fades sometimes away from what people are saying and create it’s own innovation path.
No matter if I just sit at the pool, the ocean, the river, drinking wine at a nice spot or just lay a little bit longer in the bed: I come up with new ideas that I want to try out when returning to work.
Those are not magic places where a fairy appears and whispers you the innovational idea into your ear. I’m normally starting thinking about a problem I have and float with my ideas.
But: Did you recognize something here? None of these place is really where I get my work done. It’s most of time when I’m away from work.
Innovation doesn’t happen between 9 & 5
So here is what you might do if you want your employees to come up with new awesome ideas:
- send them on vacation
- give them the freedom to work whenever they want
- maybe encourage them to do some work out
BUT: THERE IS ONE BIG PROBLEM WITH THIS APPROACH: How do you capture the idea?
It happens so often to me… I have a great idea in the gym but when I return home I’ve already forgotten it. I used to carry a notebook around with me but now I capture my ideas quickly with Evernote. I have it on my phone (for the gym and vacation) and on my laptop to look through my ideas later. But I guess any online synching note program will do the job. I don’t know how to solve the shower situation…
Make your ideas social
It’s just my idea… Is it good?
What looks to you like a brilliant idea might look very stupid for others. At Atlassian we use the blog functionality of Confluence to share our ideas with the whole company. We have a very collaborative culture, so people write lot’s of comments to your post. In about 24 hours I can get so much feedback for my idea (especially if I was totally wrong).
The path to good ideas
- Find your innovation places (It’s not your desk)
- Start thinking about a problem or possible solution
- Write it down
- Spread your idea and get feedback
So it’s September and the conference season starts again. I actually wanted to do a little bit less travelling this autumn, but looking at my schedule for the next months I can forget that. So if you want to meet me here are the places I will be:
10th – 12th September: Oslo at JavaZone and Atlassian User Group
25th September: Berlin at Berlin DoSE
At Berlin DoSE I’m gonna do the closing keynote about “Kick-Ass Software Development (TM)”. After the talk we gonna throw some drinks for the attendees.
1st – 3rd October: San Francisco Atlassian Summit
That’s very exciting for me, because I’m gonna speak for the first time at Atlassian’s own customer conference about ‘How to make good teams great’.
19th October: Kiev at Javaday
The Javaday in Kiev is a community event and I’m gonna try to Kick-Ass there with my presentation.
21st – 23rd October, Zurich at Jazoon and Atlassian User Group
I will be at a user group meeting on the 21st and talk at Jazoon about how to do better software development by kicking ass one day later.
7th November: Wiesbaden at Tools4AgileTeams
I will talk about how teams can use Git for better development workflows at Tools4AgileTeams.
11th – 15th November: Antwerp at Devoxx
I guess Devoxx is Europe’s largest software development conference and I will do 2 presentations this years. One on Kick-Ass Software Development (TM) and another short talk about not using Git!
21st November: Frankfurt JIRA & Confluence Community Day
I’m gonna do the keynote at the Community Day about the Collaboration Revolution in companies.
I still have some options out there and I will probably do some Drink Ups in some of these cities to meet with customers. Contact me if you would like to meet. See you somewhere this Autumn!
I was recently asked to join the program committee for a medium size conference in Switzerland named Jazoon. I had to review around 30 submissions and found out, that this is a really tough job. I learned so much about helping the program committee to decide if your talk should be accepted for the conference program. So here’s what I learned (and have to apply to my own submissions in the future):
Picking a topic
- look around what is currently hot at conferences
- the program committee is trying to find new and unique topics like “functional programming”. Older and not so funky topics like OSGI or SOAP are more likely to be rejected
- check the tracks and themes of the conference. Your submission should fit into those… the more the better
- be focused but not too focused – the topic shouldn’t be so broad like “Agile Development in practice” but also not like “Agile Development for left handed build managers” (I know this is a stupid example, sorry for that)
- should be interesting like “The dark side of project management” – there are so many talk submission (Jazoon had over 200 submissions for 50 slots) and compelling titles stick in the mind of the committee and the attendees
- the title should contain the information what your talk is about. Don’t shy away from buzz words like Agile, Scala Testing… so you don’t leave people totally in the dark just to sound cool (like “Huston, we have a problem”)
- a “list talk” is always great like “10 things: How to write a killer submission for conferences”
The abstract is the hardest thing and the the most important thing for the program committee. Always think about what the audience needs for deciding if they should go to your talk or not. So here are things that your abstract should contain:
- what is the problem you’re trying to solve
- why is your solution interesting?
- tell a little bit about your solution - This is the most common problem I faced when reviewing submissions. The program committee has to decide whether your solution is interesting and new for the attendees or if you will tell already known things.
- don’t tell everything about your solution; You need also to surprise people in your talk ;)
- don’t make it sound like a product demo
- try to close with why you think people should come like… “We will present tools and teaching material that you can take directly into a school or programming club to get kids to start coding.”
- Be concise: Your abstract should be maximum 250 words
- check the grammar: Show your abstract to someone else, especially if you’re not a native speaker like me!
- 1-3 paragraphs
If you’ve already have spoken at one or more conferences tell this fact to the program committee. There is often a field you can fill out like “message to the committee”. If not: consider to add it to your bio. Sounds lame? Maybe, but the committee knows that you’re able to do a presentation and other conferences have already excepted you in the past. If there are videos of your talks, send the links!
If you don’t have experience in public speaking, take a video cam and shoot a 5 minute video of you presenting. Add the link to your submission!
And Now: Good luck and see you on the next speakers dinner ;)
I never understod why companies are building a strong management driven culture and destroy the creativity of the developers. We need freedom to build awesome software with great quality fast. That’s why some people see us as the prima donnas in a company. When our management gives us the freedom of choosing our own tools and processes we have to turn that trust into productivity and quality. We have to find a great development culture that we live and breathe every day. Culture is so important:
“Culture eats strategy for breakfast”
These are my 7 points how to build a great development culture and give the power back to the developers. It may not be complete but things can’t go really bad if you can follow these things:
1. Find a way to deal with customers
Customers suck! They find all the bugs and call you in the middle of a great pair programming session and destroy your mojo. It’s not a good solution to let just the support or some product managers deal with customers. Try to send developers to your users. Let them see how the tool is used that they are creating day in and day out. It’s not easy to find the right balance between “Getting things done” and learning the needs of the business. But your culture should make this absolutely clear: Everybody has to be at the front line and know what’s going on in the real world. Do daily stand ups and discuss customer requests. Meet customers frequently. This gives us the power to build the best software from a technical and a usability stand point.
2. Don’t be evil to your software (and don’t let other people tell you to be)
We all had this situation: Your boss or your customer asks you to do a quick hack. Just a small change that will drain your quality or it will just look bad. We want to please the people that are responsible for our payment. BUT: We have standards. We have to deal later with the technical dept. We have problems with scaling the software. Stay true to your principles. Say: NO! ..and at the same time try to educate your boss or your customer why this is a bad idea and why it’s important to hold your software development values high.
3. Show people why they are important
Why do people go to work every day? Yes, to earn money. But this kind of motivation is losing more and more traction nowadays. If you earn a certain amount of money, rewards doesn’t motivate you to be more productive in the long term. People want to get appreciated by humans for what they are doing. Not just once a year when you have your yearly conversation with your manager. Do it whenever you think: “Cool, that was great”. I had a great experience when I’ve send one guy from the team to the customer just to see how they use our software. He came back and said: “They really are productive using our stuff. They love it”.
4. Do your own thing
There are so many good ideas out there in the world. Don’t follow all of them. You should just pick those, that makes sense for your team. Don’t try to implement Scrum by the books. See what works, what doesn’t, get your own ideas and try them out! Don’t follow blindly another Guru that is trying to teach you the right way.
Developers should have the right to decide what works best for the team. But we’ve been studying for years, we fix problems every day and can’t decide how we work best? Developers should be treated like grown ups, not like 13 year old school boys. If we think a tool makes us more productive, let’s buy it!
5. Learning is everybody’s own responsibility
The company can send you to conferences or workshops and they can buy you books. But lets face it: You won’t learn anything from a 45 minute talk or if a book is just laying in the shelf. You have to take action! Nobody can help you with that, it’s your own responsibility. And we have to learn if we want to know what’s going on. Yes, there are some things to do together like coding katas or brown bags. But also here: It’s still the decision of each employee to take that power and use it for something good.
6. Change is the only constant
Do I have to say more? Think constantly about what sucks in your software development and change it! Don’t be afraid of new things or to pull the plugs on things, that have just currently been implemented but really doesn’t work out. Change and improve constantly.
7. Focus on quality and dev speed
Depending on the product you’re developing one or the other is a little bit more important. It’s sometimes hard to find the balance: If you put too much effort in quality, your deliver speed will slow down. If you’re delivering like a maniac, your quality will drain from that (you will see it in the long run). It is really important to always keep thinking about these two factors and to talk about them in your development team.
Credits for the pictures:
Couple designed by Jens Tärning from The Noun Project
Electrical Shock Warning designed by Travis Yunis from The Noun Project
Blindfold designed by Luis Prado from The Noun Project
Approve from The Noun Project
Interchange designed by Laurent Patain from The Noun Project
Speedometer designed by Olivier Guin from The Noun Project