Category Archives: Technology
There are those in the Startup/tech community who often say “stay out of my way and let me do my job mentality” to Government.
Take this article for example: JUSTIN TRUDEAU SHOULD DO NOTHING FOR STARTUPS
This feels like a lack the understanding of how Government at all its levels can impact on the ability of the business community to grow and be global champions.
I spent four years in elected office at cabinet level (Cornwall County Council, UK) with one of my remits been Economic Development of Creative Industries and for the last seven years I have being a part of the Vancouver Tech/Startup scene. This has given me some experience, thoughts, problems, solutions for what any place that wants to consider Startups as a part of their economic strength.
I worry like many, that Vancouver will become a resort town.. technology is one pathway to diversify it. Over the last decade I feel the BC Provincial Government has failed actual Startups (those who are not large Tech companies), at time that could have made a real difference, they made their economic focus elsewhere.
Here is a list of areas to explore before the Provincial Elections in British Columbia in 2017.
Most ideas/solutions/problems will have to be solved in partnership with Vancouver City, Federal Government, businesses, teachers, unions and many others.
1. Listen and understand what Startups offer – not just “leaders talking to leaders”
By engaging with the industry and community leaders to explore approaches and strategies both with the leaders and their employees.
It needs to be wider then the traditional old boys network, so not just friends/connections/trade associations. The traditional group of “talked to” are generally mostly men, white and from well off backgrounds. Talk to women, which our sector is so sorely missing in the top positions. So talk to people like Maura Rodgers or Jenn Cooper people who have created actual communities. Look for who is excluded and work out why.
2. Understand the businesses at their different stages – Not just one type of entrepreneur
By exploring the different needs of different sized organizations whether they are small, medium or large. It tends to be the larger ones that can afford lobbying, lets not ignore the small. The needs of Hootsuite are different to those of a five person startup, or the startup whose main target is a non Canadian market i.e Payroll Hero.
3. Involve Traditional and non Traditional Education institutions
By ensuring that all teaching and training organizations (including schools, colleges, Universities, bootcamps i.e. CodeCore and other private training organizations) that educate or train people are involved in the on-going journey to strengthen our knowledge based economy.
It seems that some of traditional educational institutes only talk to the really large companies i.e. E.A. or Sage or SAP. They often want experience with a C variant or Java. Whilst most startups want a framework/language that lets them to get up and running within a 3-6 month window and experimenting with a product to market fit. They do not always have time to train a person in a new language. Some Universities in the US have recognized this and have Startup Engineering programs i.e. Stanford.
I think Bootcamps and on-line learning platforms are an important part of our future learning culture as they adapt much faster then Universities and Colleges in which programming languages/frameworks/techniques to teach.
P.S. Who teaching people how to learn? Schools, Colleges or Universities?
4. BC Training grants DO NOT recognize online learning
This is the case for monthly subscription learning which can occasionally have the most up to date knowledge. In a place the size of BC it is not always economically to get a trainer out to the middle of no where. The mentality of BC Government is that they want you to give a job to a trainer and get them to train your people in personal. This can be very expensive. Reduce the barriers to learning not increase them. Are they environmental benefits from delivering online?
5. Developing effective skills training in schools
By exploring which skills are needed in an effective knowledge based economy. That these skills become fully understood and clear strategies are developed to to ensure they are gained from School upto University e.g
- Change management
- Conflict management
- Risk taking
To consider how these skills compare on the Global stage, Vancouver/BC is competing against every other city/area on the planet. What are Vancouverites poor at, how can we improve it? I feel that I have seen a lot of conflict avoidance (rather then conflict resolution) in my time in Vancouver is this just my experience or is it a “Trait” of Vancouver? Lets understand our vulnerabilities and counter them rather than ignore them.
6. Growing Entrepreneurship
Entrepreneurship is encouraged at every level of education, from school upwards e.g. Young Enterprise in the UK. It should become part of the school system to teach children conflict management, understanding risk, managing stress and managing change. Maybe the program should consider Social enterprise and not just be limited to private enterprise.
7. Coding for all ages
I am not convinced that programming is for everyone, we humans are far much more diverse then that. One UK programmers’ feelings are well expressed here – Learn To Code, It’s Harder Than You Think
But we should consider Programming a good way to teach problem solving, logical analysis and critical thinking and not just as a career. As it is in UK, US and Nova Scotia.
8. Career changing
Why do Governments only consider this when the shit has hit the fan? Its a reality of now and the future, there are no jobs for life. We should teach the reality in schools, rather then just try and box people for life in a career through poor decision tree mechanics.
How do we make this easier and less feared, almost part of our natural lives like it will be for any Gen Yers.
Consider how people can support themselves whilst re-training, consider how to make this possible for shift work. Consider online as well as physical education.
Developing alliances between industry and research institutions to create innovation infrastructure is of courses necessary, and some exists, but is currently poor. Maybe make some of the “intellectual property” known about.. Hacking events? Open Transparent patent libraries, people whose job is to market their intellectual property.
10. Support the jobs that are actually needed i.e. Software Engineers not just Post Grads
Most government programs support PHds and Masters, but we actually need far more people with Bachelors in Software Engineering. Also what about the 40% of people that learn programming themselves? Could we better support them they are a large chunk of our software environment.
11. Support of growth Technology Leaders
Consider how to support the next generation of CTOs, from co-founding to a full CTO with a scaled up business. There are many programs that support the CEO/Founders but to be truly successful you need the product to scale. It seems like we have few homegrown success (if we do why not celebrate them rather then just the CEOs?), most companies want “magical” tech “genius” or “star” or “rockstar” or “ninja” from some other country. We have no programs to support Tech Founder to CTO, why? To have a successful tech community we need many of these people.
12. Open Government – Community, Procurement and Solutions
The Government needs to lead by example and considers how startups/SMEs can help them in all aspects of their scope, make parts of their systems more efficient e.g. innovate through Government Hacking events, fairer procurement procedures for SMEs. That Startups are looked at like NGOs as a possible solution to a problem i.e. how to make government delivery of services faster, more efficient. IBM or other large corporates are not the only ones with solutions and frankly some startups could beat the large corporates in producing solutions i.e. The Obama health online system
13. Social Enterprise
That Startups who work with Government or NGOs, should consider sharing their success with Government and/or NGOs who were core partners. For example either paying back any, grants when they can afford it (i.e. making a lot of profit), or even better give a number of shares to represent the initial investment or revenue sharing.
14. Evolving beyond “Me too” products
To consider how we can come up with something new, rather than the solely Canadian version of this or that. I feel that productivity in the innovation economy comes from generating new ideas that generate new revenue. Yet where is the support to take Visionary or high risk projects in B.C.? I hear many people in Vancouver tech conferences call for this, but the Angels do not invest in these, IRAP does not invest in these. NVBC never lets these through. We need some way of support high risk ventures, yes maybe limited it per year, but something.
15. Why the basis for B2B and B2C in BC?
Explore what we in BC have failed to produce more successes with B2C companies here, as we seem limited to B2B. Why?
16. Avoiding the Social Problems seen in Silicon Valley/San Francisco and Seattle – “Cruel Gentrification”
For us to consider a kinder approach to gentrification, bringing the startup community together with the community they often displace, and develop solutions that could help both succeed. There was an event to explore this but it was more hype then solution based. The solutions offered were just give more money to charities. It like many meetings really avoided Gentrification. We can see this happening in Gastown and to some degree China town, how can we create a proactive “kind gentrification”?
17. Involvement in Policy
Canadians entrepreneurs can help our policy makers design strategic policies for intellectual property rights in trade agreements, judicial strategies when ideas ownership is on the line, technology standards strategies and many others. And please talk to people outside the “Canadian maple syrup mafia“. I am not discounting their wisdom/experience but we need the next generation involved to and those who are currently excluded.
18. Upgrade SR&ED
First of all Thank You (yes I know its federal). It does make a difference. But make it easier to apply for the smaller startups. I think the documentation process is so complex that now consultants help lots of companies, or worse startups have to invest a lot of time in it. This program needs to be streamlined.
19. The ability to solve a problem
They maybe some that think that start Startups are just for making money but like NGOs they can solve any problem. Software Engineers are problem solver machines. This is a resource under used by Governments at every level and by every party. There could be Startup Weekend events or Hacking events that target specific areas of concern i.e. Government, Health, casework database, transit systems, etc Maybe Government contracts should include a clause that every large spend on IT systems should work with Startups or support the community in some fashion. Or maybe you have a open competition over a week and compete startups against corporates?
20. Explore the support of turning a service company into product
So two companies that evolved products from a service company (Web Agencies) Vision Critical and Hootsuite. Is this something we can repeat, is there a way to support this?
21. With Industry define targets of success could really look like
By using the above to develop achievable targets for expansion with specific strategies linked to specific industries.
A friend (non technical) recently asked me how I lead my dev team, he had led product and marketing before, so I have attempted to focus on the differences, that said good team leadership has commonality with all disciplines.
I currently have three software engineers, one IT/Dev OPs and one product designer (3 female and 3 male). In the past I have led 23 teams. I will use this blog for my team to hold me to account 🙂
Being accountable for “no surprises” is the core. Where ever possible you should be accountable for all of the people that you work with, people should not be surprised by what you say, because you have already asked their opinion, maybe even evolved your thinking and they can see the process by which you went through to reach a decision.
It means more communication and more interaction with your people. It means you can be vulnerable. It means stepping outside of your “assigned” responsibility and forming relationships with all parts of your organization, and other organizations. Its about being connected, its about being a leader and a follower. It shows that people understand you and your core principles. That you can be consistent and when you adapt they can see that to.
There are not things left unsaid, you are not passive aggressive or have control issues.
Being a Leader of context
The role you take on should change depending on the context. Sometimes you are the coach, sometimes the mentor, sometimes the friend, sometimes a psychologist, sometimes the engineer, sometimes the product owner, sometimes the user advocate, sometimes the engineer advocate, sometimes the leadership context, sometimes the inspirer, sometimes the critic.. There are different leadership styles and yours should adapt. In 2003, prior to my MBA this book really helped me step up my game The New Leaders: Transforming The Art Of Leadership Into The Science Of Results
You are the right person at the right time
Different places/ways to work
People are generally smarter/productive longer, when they can have different types of environments to work in and have multiple ways to express themselves. Have multiple places that engineer can work in. When I recruited my current team, I got the organization on board with the following:
- Give the engineer a laptop
- Have somewhere comfortable to work e.g. sofa, kitchen
- Have somewhere serious/quiet with extra screen
- Have somewhere they can stand up and code
- Have somewhere outside if possible, natural light/fresh air is a great refresher
- Make it possible to work remotely
- That there are white boards for people to express, figure out a problem.
This is a good book if you want to really consider your culture and the way you work. The Best Place to Work: The Art and Science of Creating an Extraordinary Workplace. Without doubt you should ask each team member what helps them concentrate, what distracts them, what they need to stay in the zone. The obvious big one for many is a good set of headphones. Do not underestimate the quality of a good display also, anything at the quality of a Retina can reduce eye tiredness.
Different physical environments can refresh you, help you think bigger or focus. Be flexible.
Leave chunks of time to code
Engineers are generally more efficient if given chunks of time to code. Thus have your meetings meetings near mornings or lunchtime. To give several hours of interrupted research/code time.
- Get engineers to block out their time on their calendars, so product/founders can book time when needed
- Use an IM system to ask questions such as Slack or Skype during those chunks of time and do not expect a quick response
Developers need chunks of time to be left alone to get on and focus
Being a good human being
This means understanding each others needs and wants. Expectations both from the lead and engineer should not be hidden, things should not be left unsaid. Sometimes we need processing time, to check in destructive emotion, but you should still tell that person how they made you feel. You should also be kind but not nice.
Both people should be able to be vulnerable with each other and trust each other. You both need to avoid surprises. This is done through good communication, which is not common and takes effort. This needs time together.
- Feedback in the moment, always ask permission before giving feedback and make it about the behaviour you saw. Do not assume intent, in fact assume positive intent. Give positive and negative feedback. Understand how each member likes to receive feedback. This is my slide deck from teaching my teams about feedback.
- Weekly One to One checkins 10-30 mins, any fire issues? any smoking issues?
- Monthly sit down at least one hour. I have a list of questions to always go through, which we agree when we start together.
- Allow others to lead, giving opportunities to members of your team to lead on a project/task whatever you do not need to be the boss of everything.
Question set for monthlyFirst conversation should be to agree the questions, here is a starting set. They should based around the culture we wish to create and how we want to treat our people
- How are you feeling? Any hot issues we should talk about?
- How are you contributing to the company and your team?
- Are you a Team player? How are you involving others in your process?
- How are you growing/learning? Are we are helping your reach potential? Do you have mastery?
- What are your Technical Capabilities here? Where do you feel competent?
- How are you helping the company grow and evolve?
- Are you Hungry? How productive are you? Are you taking inspired action?
- Do you have a friend here?
- Do you have a mentor or coach in the company? Are you coaching others?
- Do you want stay with the team and the company?
- What can can we do better as an employer/me as your leader/CEO?
- Do you feel you have Autonomy? Are there things stopping you doing your job?
- Do you feel you have Purpose? Do you understand what we are building and why?
- Are you contributing to the wider community? What can we do to help?
One to one, face to face is the highest bandwidth of communication
Your processes and system should evolve.
The way you do things should be Agile (as originally intended i.e. flexible and evolve NOT rules). Agree a workflow together from product to engineer. It should change and evolve to be right for the context.
- When starting with a team, I will audit all current systems and ask for each members views privately on each tool/system/process, to ensure the less confident or shy people get their say
- I will then have a team meeting to review what we need and what we like
- Any team wide system change should involve all parties
- Deadlines should have engineer involvement and not be dictated downwards
For example in my latest team we discussed the tools we wanted and we decided to use
- Slack for IM
- BaseCamp for idealization and research
- Github for product/features/user stories and code/issue management – The way we used tags evolved several times.
Freedom to solve the actual problem
Sometimes Product/founders/Engineering leads may try to solve the problem in their way i.e. micromanage. Giving the engineer the “code monkey” role of just coding to a very prescribed way i.e. an exacting feature. Giving no space, to actually problem solve can be very limiting and create an environment where creativity and innovation are stifled i.e. the evil called micromanagement. Most humans do not like their freedom taken from them. So find the the right balance between the organizations’ needs and the employees. That said some people like more structure, context matters.
- Give space for engineers to solve the problem in their way. If you are already using Agile then you may evolve the story a couple times as users respond to the work.
- Within the user stories/feature requirements do not limit. Ensure you actual describe the problem you want solve, suggestion ideas/solutions but where possible do not dictate
- Involve the team in talking about the features and discussing possible approaches, but the actual engineer who takes the feature gets to decide
- Engineers should have some understanding of the customers. Ensure your engineers meet customers, and spend time with your Customer success/relations people.
- Keep the engineer accountable for the response by users. Thus have good monitoring software and have a culture when engineer go back to check the real world implications of their work.
Micro Management is the evil of leadership, it kills creativity, innovation, trust, and growth. It can appear both in a manager and in the processes you impose on your people
A culture of science
Scientists experiment many times and fail many times and one day they get it right. Encourage a culture of learning from mistakes not teasing/persecution which means encouraging experimentation and forgiveness.
- Discussion should be based on logic in reference to code
- Create an environment where people can I say “I do not know.. but here is an idea/feeling/instinct”
- Call people out if they tease others about their failures or use it to argue they case in a discussion
- Careful to not let irrelevant aspects enter into the discussion such as gender, race, age or sexuality. I say careful because humour can involve these but they should not sway discussions and the receiving of the humour should not be hurt.
Experimentation and failure should be Ok, team members should not “haze” each other. Leadership need to be able to move on
To build a team well, needs reflection and the teams involvement
The team needs time to connect as a team and evolve together as a team. We have a book club where we talk about the teams performance in terms not related to code. How good are we at communicating:
- Giving/receiving feedback
- How do we react to others ideas?
- Who do we go to help us through problems?
- Who pair code with more often
- How much do we know about each others strengths and weaknesses?
- How vulnerable can we be with each other?
We used The Five Dysfunctions of a Team to kick start this conversation. Every couple months we take time to talk about how a team we are in terms of communication. You need to invest in the actually team to have a team..
You need time for the team to talk about the team, spot weaknesses and evolve
Ask your people how you are doing
“How am I doing?” should not be a hard question for you. Ask it informally in your one to one monthlies and formally at least every 3 months. The no surprise rule should be for all. It should be 360 your leaders, peers and your people. Find out if people get what they want and what they need from you, in terms of communication, conflict/challenge, advice and performance.
You learn faster by other people telling you what you are doing right and wrong
Collaborating with your leader
Hopefully you chose your boss carefully when you were recruited into the organization.. but things evolve, so maybe that perfect person you went to work for, moved on. I have found the best leaders are those who keeping growing i.e. they read about how to be a better leader, they can be vulnerable with you and you can talk openly. When you make mistake your instinct is to tell your boss, when one of your team performs really well you never feel the need to take credit and generally you have no fear of your boss talking to your team. If you do find the above hard, understand why.
- Never underestimate the amount of time you will need for your leader
- Know each others strengths, weaknesses and blind spots
- Find those things you really enjoy about each other
- Find those things that you find difficult and talk about them
- Build strong relationships throughout the organization, ensure all find you approachable
Success in any organization is about working together and helping each other evolve
Adding to the team
Whilst you as the lead will drive this process, you should involve the team in the process. You should ensure everyone is trained and good at the interview process. This may mean mock interviews, where your team interview you. Its worth noting that you do not want more clones, you need different types of people, skillsets, who sometimes will clash, but have the communication skills and reasoning capacity to grow from each other.
- Be clear what the team is missing and what you need
- Agree on what you are looking for both terms of technical and personality
- Ensure the all those that are interviewing try out their questions, again no surprises
- Have space for something social
- The best interviews are like a great chat amongst friends about something technical
- Personally I hire on communications skills, problem solving skills, learning capability and then current technical skills
- I often look for potential as much as current craft capabilities
- I do not hire more of me, I want diversity
- If employing someone with less experience, be clear what the areas are and put in place a training program to fill those gaps.
I look for growth potential, hunger, curiosity, pro-active, problem solving capability, how they will add value to the team and how they will help the team evolve. Then I start start to consider technical experience.
Software engineers are great problem solvers
Sometimes we box people into a role. Humans are so much more than their job title and job description. Most people are capable of applying their skills in other domains. You have a problem, why not ask a software engineer?
I will keep adding to this blog as I learn.
I headed to Whitehorse, Yukon, Canada to spend the weekend at a HackingHealth weekend. It was an amazing weekend because of the people, the event was interesting but the people I travelled with, those who I met from the Yukon and the health professionals who shared their lives were awesome. This will not be the last time I spend time in the Yukon 🙂
Most of the event was tracked pretty well on twitter #hhnorth14
Alex Greenhill asked if I would be interested and if I could get 6 other developers, the event would cover the hotel and flights. I advertised on all my social media and the ruby meetup group, django meetup group, Node.JS meetup group. Meetup.com only allows you send messages on 3 separate groups per day, new learning. On a side note it was interesting to see how each meetup group had their pages setup, some had admin needed to forward email, some had a group email and some had a separate discussion groups, with threads.
Anyways during the course of a day I had 40 people respond and another 20 over the weekend. First come, first served, and only those with full web stack and/or Android/IOS skills.
There was a Sparkboard platform which was a great introduction to ideas (Built by Matt Huebert in Node.JS). Here is this events collection.
Vancouver Team is set
Friday – Meeting the team
We were a real mix of personalities and backgrounds. Amazing bunch of people.
The Yukon hospitality really was evident from the beginning, we were picked up from the airport shown and around and dropped off at the Hotel. It was hot here, I needed my shorts and suntan lotion!
The Venue – Kwanlin Dun Cultural Centre
It was an awesome venue, big place, big kitchen and you step outside and it was so peaceful.
The teams and ideas
All the ideas were given 60 seconds to pitch their idea. And then everyone talked to people, to discover which team to work with.
I had some great conversations with doctors, nurses, social workers and other technologists. I learned so much about Health in Canada but also about health in the Yukon. And it did not stop there I learned a lot from a social worker there about the local issues, culture and their specific problems.
Brooklyn and I noticed that health discovery was mentioned in a number of projects, so we felt that if we abstracted this problems we could in theory support all three of those projects. We decided from the gecko our purpose, we wanted to build something that help others build out their software quicker. Hopefully allowing participants at Hacking Health to build something greater.
So a lot of the food was made in the next door kitchen by volunteers. It was a good variety of health food and there was often vegetables and fruit available through out the day. Some of the food was made by the Alpine Bakery, yum, yum..
Whitehorse, I like it..
You know I love small towns, where people will look you in the eye and smile. When conversations are easy to start and continue. I suppose its the county in me, people that just enjoys people, and when we don’t we loose ourselves in nature.
Like seriously where else would you be invited to paragliding for day, join a family for dinner, go to a wedding, asked you want to go fishing, bought a couple rounds for drinks, get a bunch of invites to cabins to drink, where you would get a free guide to show you around — at Whitehorse, Yukon, Canada
Saturday – Day of coding and interviews
A lot of the day was spent coding, with breaks to interview different health professionals as they came in, about the health care system and the Yukon.
Interviews – Physician , Nurse, Patients and social workers
Turnover is higher in remote areas, as people come for their “Northern Experience” and return. The work is very varied and you have less choice to specialize or not to do, work you do not like. The work can be “brutal” and its likely most of your work will be related to alcohol or drug addiction. Everyone knows everyone so people notice if you go to a sexual clinic. People are not aware of what programs are available and awareness of new people takes times. Most doctors are self employed and are paid for “fee for service” i.e. paid for appointments, that doctors are not paid for preventive care, thus they reword the appointments to get the patient what they need. The Canada Health Act responded to doctors not taking enough appointments, but has created a situation where preventive is not valued and that doctors do not get paid for going to community meetings. Building trust takes time with remote communities, turnover hurts more than in the cities. People are often confused which service they should access. A number of people stated they were often confused by language used by Doctors and what was on the websites. It was mentioned a bunch of times it was not clear what services could actually offer.
Learning about life in the Yukon
Most business is done by phone not by email. Here there is no phone signal between towns. Most have blackberries if they have phones at all. WIFI is uncommon. There is no Rogers/Fido up here. There are a lot of cabins, with no power, or running water. Most cabins need wood stove to survive the winter.
During the day there was a fair with a helicopter ride. It was a lot of fun.
Sunday – building the pitch
Health Geo was our pitch. Saturday Brooklyn and I coded a lot. Sunday was split with me building a pitch and Brooklyn finishing off the basic funcationality. By the end we had a working project which would allow you put in locations add information for each of those locations e.g. abilities, symptoms. It took us longer then we suspected it would. But we both know a lot more about location services now! It was not pretty but with just a team of two it worked.
There eight pitches left out of thirty ideas. We each got three minutes of pitch and two minutes of Q & A.
David Saint-Jacques (@Astro_DavidS) spoke of his journey to almost become an astronaut and training he went through. I really enjoyed it and he came over with confidence and humality. He later came out for food and drinks. A good guy.
Awards were given out to six of the eight pitches. You can see their spark board summaries here.
With a double award (Popular vote and Health Tech consultation award) going to voicemail for the homeless, using Twilio as their base technology – ReachMe led by Leigh Ayton, social worker .
- “Yukon Baby” for winning the Design Consultation award, led by Chris Nayor MD
- “COPD Action Plan” for winning the Bonnie Walker commercialization & consultation award, led by Bethan Davies, health professional
- “RelievR” for winning the Outside the Cube consultation award, led by Jonah Marek MD
- “3D-printed finger splint” for winning the Technology Services award led by Sam Fleming
Dinner and Drinks
After the work it was time for some fun. We got a space at the Klondike Rib & Salmon Barbecue, the food was great and the waitresses were sassy, one even took a sip of my drink to make sure it was ok 🙂 After we headed to join the organizers, volunteers and an astronaut to drink further.
Heading out of town we went to Andrew and Alyissa’s cabin for drinks and a campfire. It never seems to get completely dark here. Thanks to Sam for driving us out and Jayden on the way back
The Whitehorse team and community
I feel incredible grateful to had the opportunity to be a part of this. This event felt like no other Startup Weekend/Hackathon I had ever being to. It was clear people had put a lot on hold to get this event up and stay running. There were many stories of things falling through yet Ben Sanders and the team, kept it on track. Ben, Andrew, Alyissia, Aarti, Shreya, Tina, Sam and all the others behind the scenes – Thank you 🙂 I wish had worked less and got to know the rest of the volunteers more.
I think Whitehorse would be a great place, where people come up for a couple months, working on their own a software project, maybe they could get a reduction on rent and food for working on local community projects.
Suggestions for Hacking Health:
The event was fantastic, here are some ideas to build on the great work you are already doing.
- There should be a pre briefing about the local health/social issues. This could be a Youtube video or it could be the first session where all can get involved. Either way this should be pre pitch.
- Judging panel should have one developer on it, this is a combination of technology and health after all.
- Create a list of all ideas at HackingHealth events and a list of all pitches given. Sometimes ideas help others develop better ideas. Also people with similar interests may find each other and starting building together outside of the actual events.
- It would also be great to have a quick reference guide to all the privacy limitations specific to the Province / Nation as Hacking Health is international (Seth)
- Health like Education has the great potential to build lego blocks that other teams in the future could use. Encourage people to share and build for future hackathons. Most projects are too big to build alone. As developers we are often abstracting the problem, as we see common problems in different places, we are not limited by departments or silos, we look for the common problems and then common solutions. Most of the code used in one hackathon could help other hackatons build more, or even just copy and thus build complete solutions. Encourage this behaviour and bigger things will happen.
- Jesshan and Matt you should tell your story on the About section of Hacking Health.
Monday – Getting out of Whitehorse and into the Yukon
Some of us stayed to enjoy more. We took a short trip out of town to see mountains, desert and grizzlies. Thanks to Corin for the tour and Chris for driving..
Some places touch the heart, this is my attempt to describe it.
A moment in time, stillness
The sun down beat and I could hear the water
A bird called out and there was only the wind in trees
The view reminds you, of smallness of you
I turned around and there the humans be
Friendly, sassy and unafraid
They will look you in the eye and walk into your life
You walk into a bar and sit and you do not have to be alone long
Its not all pretty, you have to think ahead else nature will take you
There are few of the those fancy things that make you lazy
You trust in your people, your truck and dog
but that cellphone no work much
Whilst there is much light, the future is uncertain
There are many opinions of the road ahead
They agree, that there mountain be grey
But whether civilization should come on down, there are differences
This is a place to be close to nature, with light feet
A place to get shit done, to take a moment and reflect on the past and ahead
A place of good people, the practical, escapists and survivors
A place closer to the heart and a drink or few
Overall I enjoyed this conference more than last year. I am now 15 months along my journey into Rails/Ruby. I considered whether my enjoyment was because I understand a lot more rails and ruby, of course that is a part but not the only part, the people, the sessions and Chicago all made a contribution.
There were many amazing talks, good workshops and I met a lot of people. I thought all of the keynotes added value to my thought process. My favourite talks were from Sandi Metz, Sam livingston-Gray and Adam Cuppy.
I am adding all the resources I find to the bottom of this post, including photos I took of the job board.
You can find the keynotes here http://www.justin.tv/confreaks/videos and here is an amazing set of photos from railsconf https://www.flickr.com/photos/justingordon/sets/72157644405839722/
Be warned I will keep updating this page! Agile page production 😉
Prequel – The day before
Getting to Chicago I flew in from Vancouver, BC.
Guide and scholar
Last year I was a scholar so I was given the opportunity to attend for free RailsConf 2013 because I was a student and a newbie to rails. This year I wanted to help a scholar and be a guide. This started the night before the conference starts where you are matched with your Scholar and you get to know each other.
After we headed to Howells and Hood, couple blocks away it had over 100 beers on tap. Jeff (from enova, they are hiring) also bought us a couple rounds of drink and introduced us to enova the company he works for in Chicago. The drink and debates were passionate, we talked about each others path to Rails, where juniors can get jobs, the things you should learn at the beginning of your career, tech interviews and who was employing juniors.
Day One – Tuesday
Breakfast, apparently the most important meal of the day. We found Yolks a good breakfast place which was located just a couple blocks away. It had a great menu. I ended up eating breakfast with a couple randoms and a team from (NextGear Capital). I was impressed in the diversity of this tech team and they are on a hiring spree.
I enjoyed the talk, he was passionate, direct and funny. I am also a believer in free and open speech, though there are topics that challenge this belief such as hateful on sexist/racist/homophophic. This talk was none of this but it did challenge the “common way of thinking”. I wonder if he opened too many fronts at the same time?
“The TDD experiment has failed, it just makes us all feel guilty, but tests are important but they do not have to come first”
I have to say I am happy when I see tests! They are not as common as we would like to think. It makes it easier to understand, refactor and onboard new people. But DHH really was talking about the need to do it first and when done so could lead us down some architectural choices that are maybe to helpful for the overall plan. His analogy of guilt and diets in describing TDD was very good.
“We are software writers and only occasionally software engineers”
I like the analogy of being part software writer, it makes me consider more seriously the need to refactor your code. When I write emails, I often get the main points together and then keep editing and deleting. This comment made me reflect on not thinking of them as two separate “things”. As someone at the beginning of their software career this was a helpful analogy as at this time I have written a lot more English than Ruby.
I also wonder if it makes access for women easier? I read a good study – Breadth-Based Models of Women’s Underrepresentation in STEM Fields – An Integrative Commentary on Schmidt (2011) and Nye et al. (2012).
Relative strength of math and verbal abilities and interests drive science, technology, engineering, and math (STEM) career choices more than absolute math ability alone. Having one dominant aptitude (e.g., for mathematics) increases the likelihood of a strong self-concept in that domain and decreases the likelihood of equivocation about career choices in comparison with individuals with equivalent mathematical aptitude who have comparable strength in non-math areas. Males are more likely than females to have an asymmetrical cognitive profile of higher aptitude in math relative to verbal domains. Together, these two points suggest that the academic and career pursuits of high math ability males may be attributable to their narrower options among STEM fields, whereas females’ more symmetrical cognitive profile means their math and verbal interests compete in the formation of their ability self-concept and, hence, in their broader career choices.
My take away is we are in a competition, with other careers to encourage women to join us in software development. If we are open to new ways to think about ourselves, this may or may not help. Just a thought..
I wonder if this (the wider use of titles) is a good way to introduce different types of software builders into our community? After all with all these bootcamps, new types of people will join our ecology, what will they have to teach us and how do we support them?
I think we need different type of software builders on the team and having at least one computer engineer/scientist is an essential foundation. I should declare my undergrad was Computer Science. In my experience with teams, diversity is generally a good thing. Some of the best developers I have met do not have a background in Comp Sci degree, but instead have a Music degree. I also find teams with a mix in sex and culture are able to solve the bigger problems faster.
The better the readability/eloquence of our codebase will make on-boarding far easier for junior and senior alike. And if there are tests too, on-boarding becomes even easier! We need the artists and the scientists. After all the ruby/rails community will have to include a lot more people to have a healthly ecology.
Simplifying Code: Monster to Elegant in N<5 steps by Tute Costa (@tutec)
This was a good workshop and started really well, working through five of the refactor patters. I pair coded with my scholar. This was fun to help her understand more fully each of the steps. And in teaching you learn better ways to explain abstract concepts..
The hotel is right on the river/canal it was good to get some fresh air. I learned that Chicago dyes its water in the canals to get the green colour.
Ruby Coding Dojo by Carlos Souza and David Rogers
Here I stole a hour of this workshop (workshops covered the time of several sessions) before I headed for the next session which I wanted to see. The thesis was that practice was essential for software builders, just like it is for sports people and musicians. That they spend more time practicing then actually doing. They use the Dojo as a way to practice their code. Not too different from Ruby Koans idea, but they showed it as pair programming. I like it 🙂
Concerns, Decorators, Presenters, Service Objects, Helpers, Help Me Decide! by Justin Gordon (@railsonmaui)
I think he needed more time for this talk, this would have been a good workshop. He gave a scenario and then a solution. This was very helpful. His notes are comprehensive and he has included all of his slides with a repro and a branch for each example.
Mutation Testing with Mutant by Erik Michaels-Ober (@)
A good and clear talk. About the use of Mutant Gem which tests your tests
Keynote – Farrah Bostic
This was a funny talk about some of things we may have forgotten after a couple years as a developer. She believes that a customer-centric approach is essential to designing innovative products and services. I am paraphrasing some of her thoughts:
Professional obey the laws and amateurs break them
Be nice to one another, take the time to explain to other non-developers. Stay inclusive welcome people to your community. Do not become like the Java or PHP community.
Are we approaching a code inequality, where it is good for you to be a senior and me a novice? Is it a goal for me to keep you in a position as a novice
Structure inequality is a bad thing for our society. Inequality creates fear.
Technology is in a magical place. But are we talking about good magic or the dark arts? Or people who will be tolerate of us muggles and be nice to us and not scare the hell out of us and this “evil” technology. The question I have for you is whose side are you on? The Dark or the Light?
Your opportunity is to become customer centric coders.
Keep the good intentions and match with good behaviour, this is what attracted me to the rails/ruby community
No empty read me docs
If community/team matters to you will be surprised by this talk http://www.justin.tv/confreaks/b/522183251
As often happens a random group of hungry people got together at the end of the day to eat. Our group was a mix of sex, companies and levels. A number of the scholars(novices) asked why are there no junior roles advertised. Comments included:
- One senior asserted that he felt other seniors were scared of loosing their “prize” position of being able to claim high wages and move jobs easily if they wanted to.
- Another felt Seniors are lazy and do not want to take on extra “human” work load, of coaching a junior.
It started a passionate debate which was good to hear. We talked about GitHub and is it sexist? We of course we talked about DHHs talk.
Day two – Wednesday
Yehuda Katz keynote
Why we abstract and reduce complexity
- We are not unique, we want the same things, we tackle the same problems
- Software development is not a science
- Laws are not good things
- We build on abstractions and makes us better
- Shared solution, we build progresss
- It’s all about managing complexity
- These tools allow you avoid complexity
- Start at level 23 rather then 6
- Area of experimentation (new levels) are where the debates are had and then it will become part of shared solution
- The higher stack the less complex work
- Rails has succeeded in building our stack out, it has reduced the complexity, it allows us to concentrate on the business
Deploying Rails is easier than it looks by Ben Dixon (@)
This was a good introduction to deployment of a Rails stack to a VPS. Ben has a book Reliably Deploying Rails Applications
His stack was:
- NGinx – web server
- Unicorn – app server – zero time downtime
- PostgreSQL – database
- monit – monitoring – its tiny
- chef solo + knife(Server Provisioning)
- capistrano 3(Deployment Automation) rake app
Reading Code Good by Saron Yitbarek (@saronyitbarek)
Form a reading club to regularly read ruby code. Her presentation had great visuals and also a way to spend up your learning of Ruby. Whilst her talk was aimed at novices and juniors. “Book Clubs” are a very good way to explore management/leadership and frankly any topic.
Panel Discussion: The Future of Rails Jobs by Obie Fernandez and Panel
A couple statements from the panel:
- Employees are more interested in the team, and product over money
- If you are junior apply to any level of post, smart people match on personality and the ability to learn
- Average pay for intermediate 80,000 to 90,000 US
- Fear of too many bad skill levels due to boot camps
Tricks that Rails didn’t tell you about by Carlos Antonio da Silva
I did not go but heard good things
How to be a Better Junior Developer by Katherine Wu (@kwugirl)
This had some interesting perspectives about the approach you should take with the rest of the team. How to use your skills as a non developer to support the developer team. But stay on target to become a developer.
Panel: Teaching the Next Great Developers by Noel Rappin
This looked at different perspectives of how we are currently educating the next generation of rails/ruby developers i.e. bootcamps. It covered the lack of developers.
If supply does not meet demand, demand will go elsewhere.
This comment stuck me with and a couple stories were told about funded Startups unable to recruit rails developers choosing different stacks to build their “stuff”. I have encountered this personally as Rails developers are too hard to find, a few companies have asked me would I consider learning Node.js. I will have to explore this further. Jeff Casimir @j3 had some great comments:
If someone asks you to code on a whiteboard, ask them how to do I run tests?
If your company does not spend time bringing in junior/apprentice devs they are going to lose.
After there was much conversation of the Bootcamp phenomenon. A good number of the Scholars for this years conference had come from Bootcamps some with lengths of 2 months others 3 months. There were a good number of strong opinions of this phenomenon, I share a few of these here:
- Some feel that bootcamps are producing a “novice” level of software developers, not yet junior
- That some feel that these bootcamps reduce the quality of the rails community
- That the bootcamps with a certain apprenticeship of least 3 months are the best
- That some exaggerate their “employment” opportunities/success and it should be measured if the boot camper is still in their job 3, 6 and 12 months later.
- That some bootcamps are filling up all the “junior” spots in companies leaving non-bootcamps juniors grasping for straws.
- Some companies are cycling through 3 month apprenticeships
- Some felt they could reduce the pay offings as they “flood” the market.
- That the quality of bootcampers is very mixed
- That bootcamps are bringing more women to our ecology
- That with the standard tech interview most bootcampers fail due to lack of understanding of Algorithms, Data structures and use of Ruby.
- That we build frameworks, to handle complexity, Rails should bring people in who should not need to be a computer scientist.
- That they exist because the education institutes do not teach Rails/Rails, leaving the only option to learn with others being bootcamps. With startups and business driving the demand for rails as a fast prototype framework.
- Some felt it was a good thing and whilst painful for the community, we will evolve/adapt and it will help the community step up in numbers and mature.
Chicago Diner – Great vegan food. No I am not a vegan, but this was the best meal I had this week. You should go! Then we hunted down an Ice cream shop, Margies felt like going back to 1921, BIG helpings
We talked about our journeys to rails this was interesting most had come from a different background i.e. not computer science. From the people I met at the conference about 50% were actually from a Comp Sci background (A good chuck had also dropped out). Most told me one of the strongest reasons they choose Rails/Ruby was the community and how helpful they were. The journey seemed to be Rails and then fall in love with Ruby. We also talked about our worst tech interviews, wow I thought I had some interesting experiences.
Day Three – Thursday
Comedy in software – Baratunde Thurston (@)
Without a doubt the most humorous keynote and the message was do not make boring software, find ways to be unique and humorous with it. Use your error messages in a fun way. If you need a bunch of good laughs you should watch this keynote
All the Little Things by Sandi Metz (@sandimetz)
Without a doubt the best talk at the conference. Essentially she took a long IF/ELSE monster and converted it from procedure to real object oriented code.
- Small methods are good
- Refactor large if statements into case with methods
- Tolerate duplication until you find the right abstraction
- Squit test – look for bends and see types are near each other
- Are you going to write procedures or trust objects?
- Inheritance is good when it is, shallow and narrow and for leaf nodes
- case is for business logic, not choosing classes.
I need to read Sandi Metzs’ book she is also currently writing a Rails book, here is the keep me informed email page.
Pair programming with my scholar
She had a blog setup but could not get her CSS to work and was confused about the different stylesheets what they met and when to use them. And what are all these extra extensions are e.g. erg and scss. And she wanted to get bootstrap up and running. We covered
- Assert pipeline
- File name extensions
- What is sass and setup up some variables for her colours
- Quotes the difference between ‘ and “
- First bootstrap button
Let the drinking begin
Happy hour in the exhibit hall, this was good but lacking due to no seating. Which just encouraged us to go to Code climate drinks 🙂
Day Four – friday
Taming Chaotic Specs: RSpec Design Patterns by Adam Cuppy (@codingzeal)
Frank this was an awesome workshop. I learned a couple really good things from it. A really backed room.
- Pattern 1: start from minimal valid object (test to true)
- Pattern 2: control values with ‘let()’
- Pattern 3: Permutations using ‘context’
- Pattern 4: Descriptive naming
- Pattern 5: Extracting common behaviours
Pattern five was a real eye opener 🙂
Tales from the Crypt by Aaron Bedra, Justin Collins, and Matt Konda (@abedra @mkonda @presidentbeef)
This was sketch where the team walked through a bunch of security issues. I think I have to watch this one again on the video and take notes this time.
Cognitive Shortcuts: Models, Visualizations, Metaphors, and Other Lies by Sam Livingston-Gray(@geeksam)
This was a beautiful talk.
Key note – Aaron Patterson (@tenderlove)
A homourous round off by Aaron, with some balance to DHHs’ talk. You need to watch both DHHs’ tale and Aarons’ to fully enjoy. His thrust was in part that we need science in our community. Concluding with his 3 years of work on Adequate Record essentially speeding up, by 3 times certain ActiveRecord queries. His last act was him merging/pushing his amazing work.
The conference was well run and organized. There was some great speakers, great debate and lots of awesome people. Thank you smile
- First day novice track– There should have a newbies/novices track i.e. next steps for boot campers on the first day. Maybe with the 10 things from computer science you need to know, or how to use Active Record, or The 10 differences between a junior developer and intermediate, how to survive tech interviews.
- Get the community informed earlier – Maybe next year the rails conf team could state that they are interested in building a couple tracks and ask what “we” think should be in the track. Lets move the conference from waterfall to customer centric Agile 😉
- Find out what we(the community) needs – Have a way to vote on topics, and then advertise them and take offers. I think that either the way the rails conf team should get to decide, rather than a popularity vote, but new ways of engaging people in what topics and what workshops, I think would produce some interesting results.
- Level Tags – Hacking rails was delivered as a junior session. Maybe it would be worth considering adding tags to each session stating the levels that will be covered. The Novices track without a doubt had greater percentage of woman in it.
- Keeping our community “good” – Maybe we should have a community track next year, if this is one of assets how can we keep it, evolve it and stay welcoming.
- Humour – It was really smart to have the humorous keynote on day three today, it gave me energy. I am also going to build a resume, to help me find people I want to work with based on their humour.
- Food – The food, it was well, meh, with the exception of the last day. For snacks please consider nuts and fruit, less of the sugar crash afters.
- Space – Some of the smaller rooms, felt very packed and lacking of air.
- Jobs – A bigger jobs board and maybe one for people looking for jobs.
T – Shirts Competition
For those who have not being to railsconf, most of the companies in the exhibit hall stands have free t-shirts to give away. They always run out of XL so there is a rush (unlike the gold rush). These are the T-shirts I would wear after railsconf. I like them because the material is soft on my skin and the logo/text/pattern is interesting to non-developers and developers alike. Those just with their company name are a FAIL. I don’t mind advertising your company if it is comfortable and smart. New Relic = Datalution, Rackspace = Keep calm and code on, Sales Force = Achieve and of course railsconf 🙂
A weekend in Chicago
I stayed in a hostel (The Chicago Getaway Hostel), great place has a lot of events. The first night I went on the pub crawl and met three other railsconf attendees who I had not met before. The next day I slept and coded and then onto another pub crawl and met still more railsconf attendees 🙂 Had a great Chicago pizza at Chicago Pizza and Oven Grinder Co
Other resources for Railsconf 2014
- A number of interviews with speakers on youtube just search with #Railsconf 2014 – https://www.youtube.com/results?search_query=railsconf+2014
- links and decks – https://hackpad.com/Rails-Conf-2014-0gyxnR3pn9O
- keynotes and other talks – http://www.justin.tv/confreaks/videos
- Terry Schmidts’ reflection of the conference http://schmidt-happens.com/articles/2014/04/28/railsconf-virgin.html
- Here is the base for all the workshops http://railsconftutorials.com/2014/
- Big Astronauts daily recap videos by @AndyMaleh – http://www.bigastronaut.com/blog/ They are hiring http://www.bigastronaut.com/careers and have one the most interesting career pages, I love the attributes section.
The job market
The job board
If it helps, you are never ready, you will never know enough, and the key is knowing how to cope with that.
At the beginning you may have no idea or a vague sense how to solve the problem, you will look at the feature and Google it. You will write code and may even get it working and over time, hours or days it may get ripped apart and rebuilt. Sometimes you will part of the conversation, other times you will come back to find its all changed.
In my first months/projects/jobs I had some amazing moments as I solved problems and got the feature marked off the list, or I discovered that little thing that was stopping it work. I also has some tough moments, where my code was changed without any comment, or ripped apart in front of me, sometimes without comment or another time with the senior developer responding to my questions with condescending responses.
You will need to separate your self worth i.e. ego from your code. You will need to manage that nagging sense you are not good enough.
Here are some of thoughts and learnings I gained from my first couple roles as a junior software developer:
When you ‘Copy and Paste’ code, understand it
Google has become our SDK, for a lot of developers. You will search the feature and see who has done it already. Smart, why redesign the wheel! While this may get you pushing code faster, you are starting to create a gap between your actual understanding and perceived ability. This starts to set expectations with your employer and team, at some point this will crash down on you like a house of cards. So by all means find that code through Google, but take the time to understand it, know what each of the commands/methods does, understand the flow make sure naming of variables and methods makes sense in your context. Most smart leaders understand that it takes time to grow as coder, use that time to build a strong foundation not a house of cards.
Debugging – Read the error message!
The most frustrating thing for your colleagues is when you ask a question and your testing suite or your log is already telling you everything you need to know. Have you read the errors and if not understood them have you googled it? Yes actually copy the entire error message and paste it in the search bar and press return. Sometimes you will have to cut it down. Do you know where the logs are? No, hunt them down. It is also true that some error messages really are not helpful, infact they appear to lie, just look through the stack trace.. I record the really abstract ones, in my computer notebook with the solutions. If I were you write (yes with pen and paper – you are more likely to remember then) down each of the errors that you come across at the beginning, they may identify a weak point in your knowledge, or slowly help you remember not to make the same mistake.
Most of your errors in the beginning will be spelling mistakes, typos and things out of order 🙂
- Read the error message and understand it
- Understand the failing test
- Check the Logs, stack trace
- Check your spelling!
- If you have a lot of code on one line, break it out into several lines
- Read out loud
- Explain the problem to a stuffed toy or duck
- Google it
- Take a moment away from the code
- Before asking others, separate your ego from the code
Code Reviews & Pull Requests
If these are not happening, ask for them, if they are denied look for the next job. They are the fastest way to grow as a developer, whether you be a junior, intermediate or senior you will learn a lot by others reviewing you code. And you will learn a lot from watching others get and give feedback. Yes some people are dicks when giving feedback, maybe you should give them feedback on their feedback (you might even help out their friends and lovers! being able to give feedback is crucial for all human relationships). Innovation and learning comes out of exposing your code and being vulnerable to feedback.
The best Pull Request comments, point out the issue and then explain why it is wrong (you may need to train your seniors to put the why, telling the why, is difference between being treated as a child or an adult). Do not become a parrot and copy and paste, understand why it is wrong, you will learn and grow faster. I also have the habit of reviewing my pull requests on a weekly/bi-weekly basis to see what errors, if any, I am repeating, to target in my next afterwork homework.
Code reviews when someone senior or intermediate reviews a bunch of your code are incredibly helpful, in seeing what you are good at and what you need to improve. If you are alone build up a peer group, who can review each others code. Either way you should consider reflecting on your own code every month or so, at the beginning of your journey you learn so much so fast, that you maybe able to refactor your own code.
The next extension for this, is to put your code open source and then allow the world to help you improve your code..
There is even a better way to learn, yes pair coding it is like having a sports coach who is giving you constant feedback, and you get better. This is awesome from a learning perspective. Not only will you learn about the code but you will see how your colleague use their tools as well, which will may give you some productivity tips (or vice versa). Also you are likely to cut problem solving down by 50% in terms of time. This is not just a technique for juniors of course (its great for on boarding and teaching your organization code style). All of that said this scared the hell out of me when I started, I thought I can not remember all the syntax and options.. Until I saw that most seniors/intermediates would without a thought Google the function or command to see what their options are. I learnt that is not important to remember everything, but to remember that you can.. Now I am less scared.
Build out your augmented memory
Whilst watching most seniors, they would often lookup old projects to see how they had done something in the past. Whether it would be a Google Drive, Drop Box or even GitHub they would keep most of their old work. Another trick I saw was the use of notes for each task or type of task e.g. on Mac they would have a Note (or Evernote) on RSpec and have all the matchers and examples, or all of the startup scripts for spinning up a new node, etc. The point to be clear is you will not remember everything, so have it somewhere useful for you, in fact your memory just becomes the index of what is possible and where you did it last.
Also for the tasks that you need for setting up your computer, the environment and creation of an App, I store all of these on Github, to help me not forget a step, and also to keep my personalized setup (colours, BASH paths etc) somewhere, here is mine. You never know when you computer will die, or need to be erased, or you just get laid off!
Separating self worth from your code
Receiving feedback from colleagues can be tough. Some think code is very rational, logical and lacking of emotion. Thus the feedback can be equally logic. And some developers can be very cold how they deliver it, maybe they just have not developed the communication skills or patience to be a good teacher/coach/leader. I even had a couple experiences when “seniors” ganged up to give me feedback, and frankly it was pretty painful to receive. When I asked why and tried to understand I got cut off and then “shussed”. I walked away from the situation and then learned not to ask a question to a couple developers at the same time. That said if someone is a dick to you, you do not have to return it. Be the adult, because today they could not be.. I have also had some awesome experiences when my colleagues talked through issues with my pull request, explained the why and what good practice options there are. You want as much feedback as you can get.
So you will need to toughen up a bit, process and work through their comments, and when you do not understand either research it, until you do, or ask. I have to say asking another human is generally faster..
Asking when you need help
There is a balance between asking too few questions and too many. On one hand you may take too long to solve a problem and build that feature – on the other hand you may well “piss off” (make grumpy) those senior to you. This is tough, my general rule is to ask if you cannot figure it out after 40 minutes.
In my first job I think I did not asked enough, I know I would have grown faster if I had. That said when you are interrupting someone who is in the zone, it feels, well, difficult. Also when they are in zone they often look grumpy, constipated or are frowning and generally look unapproachable. You will learn the clues on their face over time on when to ask. Of course my personal view is when my colleagues ask me for help, I will always help. I have this crazy notion that collaboration is fun, yes even face to face! In the end I find it easier to work in a place where I like the people and they like me.
Growing your knowledge base
Sorry but you are going to have to do homework! Most non-developers have no clue how much you have to learn and then how fast it is outdated. My solution for this was to do between two and three hours every night, then maybe a longer stretch on one weekend day. But there is always one day completely off. When you are hungry its hard to forget that you are actually running a marathon and not a sprint.
As with all learning, you will have strengths in some learning styles. As a developer you will have to pimp all the styles. I try to mix and improve all my styles. Really understand what learning style best works for you. Do you prefer to build and hack together, do you prefer to read/process, do you enjoy watching videos, do you prefer to learn with others. What makes that new thing stick in your head? Understand this as you have a LOT to learn and process. A good book on this topic is Make It Stick
My personal choices include:
You can find my books and ratings on my goodreads profile. So far I find the ones actually published are superior, there are a lot of just e-books out there and I found have found their quality a lot lower. That said the just e-books tend to talk about the cutting edge technologies.
There are so many approaches that you should try a couple companies to see what works for you. I started out with Lynda.com, then moved onto PeepCode and CodeSchool – who are both owned by Plurasight now. Whilst I found that some videos helped with my understand, I did not remember them as well as book reading, which I retained for longer.
I have a couple people who I learnt with, we would meet every week and talk about a piece of code. Like a book club.
This is a marathon not a sprint
That thing called work life balance at the beginning of your career is frankly bollox (bullshit for non brits). That said you should make time to rest and not think about code. Reflection will allow you to actually learn the big stuff or that thing you could not connect at first, to spring understanding on you (Bong). The unconscious mind is a very powerful learning machine, it needs sleep/dreaming, a different context and maybe something creative, like music, painting to be fully powered up. Yes and exercise, dammit, it also helps. And if you are NOT single, consider those that will love you a lot longer then your job or career even, yes that includes you dog (or cat), plan that time. And if you are single, you are more likely to die or suffer a nasty disease, so make time to meet someone and live longer..
Watching other developers code
If you watch someone who has many years, you will not only learn their style in coding, how they write, refactor, and maybe even test. You will also learn how they use their tools and this can just make you a lot faster. Peepcode (Now Pluralsight) did some fun play by play videos that allows you to see some of the experts code. Or go a meetup or a conference and find people who let you watch or pair.
Reflection – Knowing your code and improving it
Every week I look back at my some of my code and research similar problems to see if I could refactor it. I sometimes look for web applications that solved the same problem and see how they approached the same problem and I consider the why, benefits and drawbacks. I go through my refactor book and look at my code and question it. I find the creation process can be different to an editing process, it sometimes seems a lot easier.
Working on one thing at a time
I found early on I would try to solve the whole feature in one go rather then breaking the problem down into is component parts. Now I divide the feature into a number of tasks and complete the tasks one by one (I even add them to Pivot Tracker or add a checked in github or write them down on a pad of paper!). This allows my brain to be wholly focused on the problem at hand, rather then holding the whole code in my brain. I find I chew through tasks faster, consider out of the box solutions more often as I have that spare RAM to consider them. I also find if I draw it out, I consider the connections and external parts to a greater level.
For every feature I now create a branch. After each task is done I push, well sometimes pull push depending on the time scale. First you will get mini morale boost, secondly you have a backup, third others can see what you are working on. AND fourth, if you need to rollback it is better to do it if you have many hooks to choose from.
Children do it far more and they learn faster.. And if that other person cannot explain, go and work where they really understand and love to explain.. The best teams I have worked on love to give advice and explain their perspective, but will also be able to defend their view, and then change when new evidence presents its self..
Relationships are important
There is a direct connection to strength of your relationships and the opportunities that will come your way. Invest in the people around you. Do the right thing by people, even when it all goes wrong. Those people are far much more likely to recommend you for your next job. Be kind.
Features and front end
Completing a feature will gain you kudos, and adding something that clearly effects the customer experience will gain you support from those that support customers and help the sales team. Having allies in all camps will help you be more resilient (keep your job) in a downsizing and will likely help with endorsements and recommendations. CEOs tend to protect developers who produce more the observable changes i.e. new button, skin, more responsive, etc. Where as the CTO will tend to protect those who write good code and write good tests.
Have Plan B, C and maybe a D
You are the bottom of the pile, when layoffs come, you are the first in line. Protect yourself have a Plan B as this is very likely if you are working at a real startup. Go to meet-ups, get to know your local community, make connections with developers, so if you do get laid off, you have people you can reach out to, so you can find your next opportunity. Having an active blog of what you are learning helps you reflect (so learn better) and you will build a following over time. Also work on some projects that you can put out there, so they are public on GitHub, if you feel comfortable to work on open source do.
Should I be a developer?
You may ask yourself this sometimes. I certainly asked myself this at times, when you may watch others craft so easily. This is often referred to as the impostor complex, check out this railsconf talk. Then I find myself, looking for an expression for fun, I find myself impatient at not knowing, well everything, I dream about exploring other code. Over time I found myself reading the source code rather then a blog piece explaining it, I started to understand more and more code, I find that I want to go back and refactor that hash search removing the [:id] and put in a fetch(), because it fails loudly. I spend breakfasts with other developers exploring what we know, what we have forgotten.. oh it appears I have the bug, no not the bad one but the one you are bitten by… I notice it has being several days since I got stuck and had to ask for help and instead I am asking for opinions. Do I know everything no, can I find a solution, yes 🙂
If you are not from a Computer Science Background
You may lack in understanding of Algorithms, Data structures and do not have one computer language down i.e. Ruby, Python, Java, or a C variant, yet.
The reality is that Employers feel more comfortable with someone that has stuck with a Computer Science Degree for three years. That said if you can describe your journey of why you are passionate about computers this may help.
The other aspect that matters is what are considered the basics.
- Data Modelling
- Problem Solving
- The ability to code a non scripting language i.e. Ruby, Python, C++, Java, etc
Some employers like to think that you understand Algorithms, but the reality for many coders is that you will never use this skill set. The places this really matters is at scale so a job at Amazon it would matter. This is the best learning resource I have found on them Grokking Algorithms by Manning publishers
You may want to create a growth plan for yourself to introduce these. Over a year work out the things you want to be good at, there are some good free course on https://www.coursera.org. It really depends on how deep into the stack you need/want to go. If you are out of a Bootcamp, consider building your understanding in the primary language (e.g. Ruby, Python) and data structures first. Consider than basic Algorithms, just the basic concepts, not the math and then play with a functional language. Learning a function language will force to think in a very different way, but do this after you are comfortable with a primary language.
Every senior who I have spoken to says that they learned an incredible amount from creating something they were curious about, maybe on a new framework or connecting to an API. Some would just explore how one GEM/package/library worked. This can also be helpful for building out your GitHub profile. That said when you are doing some much other homework this can be hard.
Choosing the right company
Medium/large company There are some who think that a junior is better off, going to a medium/large company. This approach essentially states that these companies will have the processes to mentor/coach, a bigger team to take on juniors. That said juniors have told me that there options are often limited to be first a “customer success”, or QA, or part of a front-end team and they have to work for a couple years before being promoted to a full stack team. You will be able learn over a period of time but may be limited to less important tasks.
Agency/Code Shop Another approach would be to work for a company that will give you access to many codebases ( like an agency or a code shop), thus you will learn very different things, different styles of coding and architecture choices. This may lead to building lots of Apps but only to a MVP level.
Startup Another approach would be to work for a Startup and then you will get see all the code, and be responsible the whole stack. Thus you end up be responsible for setting up the deploying to AWS which you may not in larger companies who may have a Dev Ops person. You will have to learn a lot more and faster. It is also likely you will make mistakes through your journey. This journey would likely teach about one codebase to a deeper level then the Agency approach.
Do you have any tips?
I would suggest you blogging your own journey, it will help you remember what it was like to be a junior and when you take juniors on yourself you can help them with your blog post and also remember not to be a dick 😉
In February I wrote a blog post about the lack of support for technology co-founders in BC, Canada.
I have decided to pull together an open source program/set of courses to educate/grow/upgrade technology cofounders, to increase their chances of success in their role. The first step will be to collect ideas/experience/wisdom from the community and then pull it into a bunch of classes that a person can work through at their own pace. It is my intention to build it so anyone could actually run it as face to face classes, in their local area.
Create an open source resource/courses/program that people can run in their local area to educate/grow/upgrade technology cofounders, to increase their chances of success in their role as a technology cofounder and grow into a full CTO role.
There are many, many programs that support the business/leader/ceo co-founder but few I know to support technology co-founders.
To help technology co-founders avoid mistakes, learn from others experience and build the quality product
Target audience Technology co-founder of a startup (Startup levels) with the intention of building a fast prototype to prove the concept.
To stay platform/technology agnostic
I will start with a level one startup and build through the others
Please share this link and come and contribute to the program at https://github.com/ericbrooke/ctofounder/wiki this is a wiki in which will collect all the ideas, suggestions for people we should interview, good resources you have already found and learned from..
We need the views of:
- those thinking about creating their own startup,
- those who are in it creating their first production,
- those who have supported technologists on their journey,
- those who have done it several times.
We don’t care if you have succeeded or failed share it! We need all your questions and experiences 🙂
Here are two place you can get the videos for the talks
There is nowhere to learn Ruby or Ruby on Rails in Vancouver, BC, unless it is a book or online. I like to learn with others. I even pushed it at BCIT and asked at every level..
So I decided I would kickstart my journey with railsconf. This was my first Ruby on Rails conference. I was honoured enough to win a scholarship, (I am a student at BCIT )to attend the conference (which paid for my ticket). The rest is my pocket and vacation days. I just view it as a vacation 🙂 And I need to buy jeans.. My level of Ruby on Rails knowledge is really low in fact up to chapter 6 of Learn web development with ruby on rails pre-confrence.
I took a AMTRAK train down from Vancouver, BC to Portland, WA. It made sense train, rails.. Its a seven to eight hour journey. My theory here was I would be able to do some more study on the way down. There I bumped into about 8 others travelling down from various companies to railsconf. I got very little extra work done.
Scholarship meeting up
This was fun and warm meeting of other scholarship winners and sherpas. My sherpa is Sam @geeksam . I got to meet some of the other ‘scholars’ a real mix of backgrounds and personalities . It was good to have some friendly faces (Chuck and Miles were really helpful) in a crowd of 1500 people. We agreed on a hashtag #rcguides. Lots of passionate conversation was started, about how people got into rails… but we finished early. So my first night I went on a beer crawl with the hostel… I know where I went from my credit card payments..
Day 1 -Monday
There was a lot of talks to choose from, and this will be my journey through the schedule.
The opening Keynote was by David from 37 Signals (Rails was created out of Base Camp, which is built by 37 Signals). His vision was that Rails should concentrate on the document driven web apps not the “GUI” e.g. Google maps. Rails 4 is about speed. His talk led into some good explanations on how the caching is working in Rails 4. Some cool stuff.
How a Request Becomes a Response
This was part of the intro track, designed to educate newbies about the Rails framework and the community. A quick and easy introduction starting from the browser through to the database and back. It was really basic but very well presented. There are a number of sessions on the intro track that can be found here http://www.railsconftutorials.com The wifi did not work but a smart person had a USB stick with the needed code.
Nobody will Train You but You
This was a funny and helpful talk by Zach Briggs @theotherzach, for those wanting to step up their game. His talk showed how he managed his first year of learning ruby on rails. His suggestions including writing down solutions he found on a piece of card. Build up some katas and practice them, until you can do them without any reference to anything out. He suggested visiting a couple sites including Sucks rocks, Destroy all software by Gary Bernhardt.
Monitoring the Health of Your App
Presentation by Carl Lerche and Yehuda Katz stating that the average web response time is a stupid way to measure your app by. The real world is not distributed normally. Web response are long tail, not standard bell curve. They have being working on a product to solve this problem and help rails app creators to track down the issues. The product they are working on is at https://www.skylight.io
Rails’ Insecure Defaults
A most excellent presentation by Bryan Helmkamp @brynary (founder of Code Climate). Here are the problems and and here are the solutions and here is what rails should change. Bryan is pulling together a free ebook you can signup here http://railssecurity.com
- Verbose server header
- Binds 0.0.0.0
- Logging SQL values
- Versioned secret tokens
- SQL injection
- YAML serialisation
Taking a break for sessions I decided to get to know some of my fellow attendees and spend some time working through a problem with Sam (my shepra @geeksam). I wanted to see how he broke down a problem and how he also read other peoples code. I learnt a lot.
Michael Loop @rands was funny, insightful and argued the need for the Stables and Volatiles (personality types) if an organisation is to survive and flourish, his thoughts that were the meat of his talk are laid out here – http://www.randsinrepose.com/archives/2012/11/14/stables_and_volatiles.html. What bookend or overarched, his talk with however, was a very important point – that we as a community have to be progressive, and that occasionally means leaving old stuff behind.
Reflection on the day
Awesome day. The conference food was good. I love how friendly the people are. How they will take so much time to listen and suggest. Kind of reminds of the early days of Apple that friendly community that is comfortable in taking on the world but is also open minded to listen. It surprises me how many Mac Book Pros I see everywhere, the only people who seem to have PCs are government employees! The venue is awesome there is space for everything, and I mean space to code, to chat. The WIFI is awful, really awful… The conference food was good. In the end I think I met about 50 people and introduced a bunch of people to each other. All the nights events were fully booked and a bunch turned you away. To note for next conference book all the evening stuff ASAP..
I learned about the rails community and rails itself today and I liked it all 🙂
Day 2 – Tuesday
Breakfast at Mothers @MothersBistro
Keynote – Yehuda Katz
TDD Workshop: Outward-in Development, Unit Tests, and Fixture Data
I went to this workshop but they had so many problems with setup, lack of internet access that I left. That said the notes were amazing http://www.railsconftutorials.com/sessions/tdd_tools_techniques/02_integration_testing.html
The Magic Tricks of Testing
Booths and T-Shirts
The exhibitors open up and everyone runs for t shits, I managed to get six. The hulu one has the nicest material..
Designing great APIs: Learning from Jony Ive, Orwell, and the Kano model
Philosophy and principles on how you should create APIs by Jon Dahl. His points were good but he used so many other peoples indicators or thoughts it felt like watching newspaper clippings..
(i) Never use a metaphor, simile, or other figure of speech which you are used to seeing in print.
(ii) Never use a long word where a short one will do.
(iii) If it is possible to cut a word out, always cut it out.
(iv) Never use the passive where you can use the active.
(v) Never use a foreign phrase, a scientific word, or a jargon word if you can think of an everyday English equivalent.
(vi) Break any of these rules sooner than say anything outright barbarous.
George Orewell, “Politics and the English Language,” 1946
Free drink and food, good for networking and deeper conversations.
Today felt a bit more abstract with the exception of Sandis talk. The conference food was good. The wifi is terrible.. pinging shows the issue is the ISP is not doing its job or the OCC has reached its limit.. Not great for a tech conference, maybe different venue next year.
Day 3 -Wednesday
Back to Mothers for French toast covered in cornflakes
A bit disappointing… but nice photos.
This was a presentation of awards to people who have helped grow our open source community or take the time to share great code. Awesome. So many people help our open source community they should be celebrated 🙂
Properly Factored MVC
Again the lack of internet kills the effectiveness kills the workshop, but notes look awesome so I will come back to this later
Creating Mountable Engines
By Patrick Peak, really awesome and clear presentation about how to re-use your code and options. It showed us how to setup a simply engine.
Crafting Gems by Pat Allan
A good presentation where he did not assume you knew anything. Good instructor. http://www.railsconftutorials.com/sessions/crafting_gems.html also learned about https://travis-ci.org and http://rubygems.org
These were awesome either 1 minute or 5 minute talks from anyone.
Here is the first 20 to give you a feel, there was 42 to in all..
- Nick Quaranto – OpenHack
- Dr Nic Williams – Deploy your own Heroku with Cloud Foundry
- Chris Morris – Technical Intimidation
- Jon McCartie – Purposeful Code
- Bryan Helmkamp – Code Climate
- Andrew Harvey – Teaching an old dog new tricks
- Senthil Nayagam – Mobile Testing with Robots
- Miles Forrest – Cloning the Seattle Ruby Brigade
- Benjamin Fleischer – MetricFu is back!
- Adam Cuppy – “You’re doing it wrong!”
- Hector Bustillos – MagmaConf great things happen in mexico
- Hector Busitllos – The unofficial RailsConf schedule App
- Mario Chávez – Logic programming
- Mike Virata-Stone – Guard your forms with class, or any other selector: guards.js
- Ryan Smith – Rails logs to metrics
- Dylan Lacey – Giant Hamster Touching – Test Native Mobile Apps with Capybara
- rking – Pry Power: Test Speediness Edition
- Ivan Storck and Brook Riggio – Remember the n00b
- JC Grubbs – Programming Apprentices
- Brad Wilkening – Smart User Adoption Analytics
- Jeremy Green – Gemlou.pe – Easymarklet and SimpleDB.
The conference food was good. Today I looked for some practical after yesterday abstractness and I got it 🙂 Popped out to Macys for a break and to buy some jeans.
Day 4 -Thursday
Last day a little bit sad 🙂 so need something sweet..
How to talk to Developers
Ben Orenstein loads of energy and several lightning talks. Taught us all how to sing better, how to communicate better and pitch better.
Reflections on the scholarship
We met after lunch to discuss our thoughts and make suggestions for next year. This was a really excellent opportunity for me and many of the other scholars thought so to. We all agreed that we really appreciated the efforts of Ruby Central and the mentors/guides who took time out of their conference to make our journey easier and more useful.
Aaron Patterson was funny, sassy and even talked about rails. Lots of insight and advice. Some great stories of past mistakes, the need to consider what you publicize on security issues (tell the rails security committee and give them time to respond), how to avoid burnout, that we should look for happy moments.
The best keynote.
Aaron was born and raised on the mean streets of Salt Lake City. His only hope for survival was to join the local gang of undercover street ballet performers known as the Tender Tights. As a Tender Tights member, Aaron learned to perfect the technique of self-defense pirouettes so that nobody, not even the Parkour Posse could catch him. Between vicious street dance-offs, Aaron taught himself to program. He learned to combine the art of street ballet with the craft of software engineering. Using these unique skills, he was able to leave his life on the streets and become a professional software engineer. He is currently Pirouetting through Processes, and Couruing through code for AT&T. Sometimes he thinks back fondly on his life in the Tender Tights, but then he remembers that it is better to have Tender Loved and Lost than to never have Tender Taught at all.
There was an ice cream social.. and ice cream!
I am without a doubt tired but the talks I went to did rally my energy, good choice of talks and speakers for the last day.
Explored The Pearl district. Lots of buzz, posh bars, not so posh bars and restaurants. For those who know Vancouver, BC it is like a more lively version of Yaletown.
I went home after buying more books from Powells and some DocMartins..
Thoughts and suggestions for next conference
This was a really good conference, with the exception of wifi access. The venue was really good with lots of space to either hide, code or meet people. The food was good everyday, very impressive for 1500 people .There were lots of amazing talks and a friendly crowd. I am very grateful that I won a scholarship to attend. I wish to thank Sam, Miles, Chuck and Marty for making this such a great conference experience 🙂
These are just suggestions that may make it even better:
- Have a day before the conference start, that is for beginners and newbies a bunch of workshops to get people up and running on rails an understand the basics. Anyone can attend or not.
- Ask every presenter to tag their presentation with Beginner, Intermediate and Advanced and maybe also type e.g. overview, into code, workshop. Allowing the attendees to choose smarter. Even give the option for speakers to give 20 second videos that state what they will talk about.
- Have a local server with all the code needed for workshops, assume that the ISP will not provide, have plan B
- Have a list of presentation mentors, who can support the building of presentations both for main conference and lightning talks
- Have some advanced talks which they are presented on the web pre conference and the actual conference sessions get deeper or have debates..
- Make fruit available through out the whole day, better to be fruit powered then fat sugar things
- Give the opportunity for people to vote pre-confrence the sorts of talks that people would like to attend.
This may encourage other speakers who know it really well to step up, it would also give you trends of types people coming and may encourage others who are starting to get to know rails.. and possibly even deciding if this is the language that we want to use. It would also allow people to start interacting prior to conference, maybe even setup lunchtime or dinner meet ups to talk about topics that will not be covered on the big stage?
- Have some real advanced workshops that maybe take 3 hours to dive deep on something. We need to grow our experts to 🙂
- Have a system to rate or vote for best presentation at the conference.
What did I get out of this conference?
Some awesome new people in my life, a bunch of new people to pair program with, a better overview of rails and ruby, a bunch of things not to do with rails. In some ways I have a treasure map of Ruby on Rails now with parts in detail and big gapping holes.. but I am in a far better place then pre-confrence.
Made some friends in Portland and got to know this city a bit better, ate some great food, bought jeans (my last pair had holes worn on the knees, ankles and crotch), bought books and bought some awesome DocMartins. And the need to get some physical exercise!
I am super excited for the future 🙂
Straight from my cookie
Other awesome posts for Railsconf 2013
Amazing visual notes -> https://projeqt.com/jessabean/sketchnotes/4/l
Awesome notes -> https://gist.github.com/jianxioy/5498969
Top 7 learnings -> http://www.hitthebits.com/2013/05/railsconf-2013-highlights.html
Jobs advertised -> https://github.com/blairand/jobs
If only somewhere Vancouver,BC would offer a course in Startup Engineering/Architecture?
Like this http://startup.stanford.edu but maybe it could be something better, that trains up developers into potential tech co-founders? Where they can build more then just a web app, with their best coding language, where they are prepared to bring other developers on board, where the basics of dev ops are discussed, when the architecture was thought through. We seem to do a lot to grow our potential CEO/business lead co-founders, but what about the tech/dev co-founders?
but where are offerings in BC for technology? Most of these offering concentrate on finding the “right” business model.
Most the tech/dev meet up groups concentrate on one religion, sorry language or another…
So what could this offering look like?
What else would you suggest?
It feels a real technology gap, which people have to learn and fail by doing.. could there be a way of bringing this together, growing more tech co-founders?
Related example includes: Bitmaker Labs offers one approach.
Another Alternative is Dev Bootcamp pointed out to me by Dean Prelazzi (BCIC), thank you :–)
Quora also has a couple interesting discussion on what is web application architecture –http://www.quora.com/What-does-a-web-application-architecture-include
My favourite books on his are soooo out of date:
Key Players who could make a difference
So I have e-mailed the key players in Vancouver, asking their thoughts which I will summarize:
- Launch Academy – interested in discussing – I will assist in thinking through their technology educations
- Grow Labs – connecting me to tech cofounders – nothing yet
- BCIC – Its not a priority
- UBC – sent email to dean 22 feb – no response yet
- SFU – sent email to dean 22 feb – no response yet
- BCIT – sent email to dean 22 feb – no response yet
Who else should I contact?
I was recently asked what are the sites or the blogs you keep up to date with. I will not add the solely programming sites I follow. Happy to take other recommendations to add to the list 🙂
First without a doubt subscribe to the Startup Digest
hacker news is very popular but it is a fire hose of information – http://news.ycombinator.com
The street fighters of startups. Connected with 500.
This guy is doing a lot to help us understand startups and the communities they need to exist. His blog is more personal , you feel like you know part of him and his journey. Connected with TechStars.
A man with a lot of wisdom. He has built up an impressive community in which he engages. Connected with AVC.
Occasionally has some really interesting posts
This used to be a really good site but now just feels like a marketing machine
InfoQ – I love InfoQ they have great videos, great tips on how to handle specific technical issues http://www.infoq.com
Smashing magazine – For design it is the king of the hill – http://www.smashingmagazine.com
Mozilla Developer Network – My favourite reference site for web stuff https://developer.mozilla.org/en-US/
W3Tech – Which technologies are in favour – http://w3techs.com
Ted.com – just in case you do not know – do not just watch the videos you thinking might be interesting, find ones that may challenge or add another perspective to your life.. http://www.ted.com
DZone – The odd good technical article – http://agile.dzone.com
TechVibes – Great for Canadian startup news – http://www.techvibes.com/global
GeekWire – http://www.geekwire.com
Tech Crunch I used to read this but its re-design actually offends me – http://techcrunch.com
Community, Incubators and alike
Awesome fun for your weekend and a great way to find people you want to work with.
The place for the scrappy startup
The professional startup educators. Check out their online TV series “The Founders”
For the elite and the top of the class
Accelerator based near the best boarding and skiing on the planet
For the startups look for funding
Business Model Innovation Hub
Formed out of the Business Model Generation Book
Signal vs. Noise – a company blog, which occasionally has really interesting articles.
Great nerd site – ANSWERING YOUR HYPOTHETICAL QUESTIONS WITH PHYSICS, EVERY TUESDAY.
Who did I miss?
You see the format tell me who I should add, thanks 🙂
These are books that have made a difference to my thinking. I have read them all. They are not all perfect but sometimes we learn lessons from imperfection as well. Overtime I will keep adding to this list.
Top two to read now:
This book is visually amazing. Some in fact may find it too visual. It is an alternative book to The Startup Owners manual by Steve Blank or the The Lean Startup by Eric Reis. It takes the foundation laid in Business Model Generation Book and focus on customers and experimenting with those customers to establish a proven Value Proposition.
The contents is solid and assumes you have not a research background or a marketing background. Yet it gives you the things you need to know to reduce false positives.
Its approach is to assume the customer knows what they want.
I highly recommend this book for Product Leaders, MBA students, entrepreneurs, startup founders and project leaders.
Business Model Generation
Need to work how your business could make money, but not sure of which way to go. This book is an amazing and essential resource in establishing possible pathways. It also challenges you to stay flexible with business opportunities. It has some excellent real case studies in how to use this technique.
Top Lesson – Your business model should be a part of your daily thinking not lost in a 50 page MBA document.
Other great books
Getting Real -> Rework
Getting real was a good book to getting started, really from the perspective that you have all the skills and people already, it felt practical. Rework was a updated version and it felt more abstract, more about the business then the product.
Top Lesson – get on with it and start simple
This book really helped me do proper market research and how to do it. It is really a step by step guide in how to build a business around an idea.The updated book was much better designed and easier to read.
Top Lesson – don’t pitch but listen to the customer pains
There is also a “cheat sheet” by Brant Cooper & Patrick Vlaskovites, I liked it because it was visually pleasing and gets to the point faster then four-steps and The lean startup.
Do more faster
This book was like having lots of friendly practical tips. The chapters are short and it’s useful as a reference for early stage Startups.
Top Lesson – Founders earn equality too
Web 2.0: A strategy Guide
This book was full of case studies of web businesses that we all know, it shows their journey and their strategies. It is helpful in helping you think through the big picture in terms in how you handle the market, competition and evolving customers.
Top Lesson – Stay flexible and be ready to adapt but do have a long term vision with game plan, in your head.
Start Small, Stay Small: A developers guide to launching a startup
This is a really practical guide to how to turn your website into a business. What are your first few steps.
Top Lesson – There are many paths to the same goal.
This book pulls together some of the best blog posts on well everything startup.
For the founder who concentrates on the business, money side, culture
Great book for first time CEO and how to survive growth.
Finding and addressing management and leadership weaknesses in organizations. It’s more relevant to large organizations but had plenty for small teams to incorporate as well.
You need to be good a telling your story, in a really simple fashion that all ages can understand. It helps you move away from bullet points to visual explanations.
Top Lesson – can you make this simplier?
Top Lesson – Those who start with WHY never manipulate, they inspire. And people follow them not because they have to; they follow because they want to.
This is told from the perspective of one person and his journey to learn the importance of organization culture. Every behavior or interaction you have will set the foundations for your Organisation. If you bully your people will copy you and bully to. What are values and principles? This book will help you start this journey.
Top Lesson – Happiness never decreases by being shared.
For the founder is more technology focused:
An awesome book how to bootstrap, written by a developer for developers.
The Art of Agile Development
A most excellent book with practical tips in how you can truly move in applying agile. This book uses xp programming as its pathway.
Top Lesson -Your software only begins to have real value when it reaches users.
This book gives a good description of clean code and how to achieve it in your own projects.It is based above some very clear principles and will help you think through the code your currently create.
Top Lesson – always commit better code then you have checked out.
How good is your code? How professional are you really? Can you say no. Do you pass the buck? Are you accountable for your code. This author puts the prefect model out there, which is a good start for a dialogue for what is possible.
Top lesson – You need to say no when you need to say no
For the founder who is design focused, UX inclined:
The Smashing Mag Books 1,2,3
Both the books and the website are an excellent for both designers and developers alike. A smart collection on web design principles. It’s a high-level view of user interaction information and has useful takeaways in each chapter.
A Project Guide to UX Design: For user experience designers in the field or in the making
A step-by-step guide to web development from proposal through wire framing to testing and launch.
Now go and build, create and show us your vision.
You want more -> If you want to see all the books I have read on startups have a look at my goodreads profile and my startup shelf