Wanted to share this great article by Lizette Chapman about how a bunch of developers earn their living by purely doing hackathons. A red bull infused intense coding session is not really for me, but these guys literally live for it.
Every developer goes through the scenario of pushing out a dodgy release to production at least once in their career. Some of us have also experienced a burn so bad it's got our heart pumping as we diligently try to figure out what's wrong whilst having the entire senior management team standing behind breathing down our necks and wanting updates … that’s not a memory you gonna loose anytime soon!Learn More
As a developer who has the knowledge to craft an idea into reality, our kind are always the last to come up with a deaccent website to make us rich (let's face it that’s the dream right!). Perhaps it's down to us being too technically focused, tunnel versioned individuals who fail to see the solutions to the mundane problems people face on a day to day basis. I think it's the perception of it being difficult.
Creating an idea is never as straight forward as it first seems. Some consider it as an art form, a practice that requires intuition, luck, experimentation and perhaps a slightly out the box crack pot thinking. For me an image of Dr. Emmet Brown from the movie "Back to the Future" always comes to mind, as he invented the Flux Capacitor when the slipped in the bathroom and hit his head on the sink.
Having thought about it I feel an idea does not necessarily need to be unique, nor does it need to be new. Eventually it all boils down to four technique's.
- Ideas can already exist, just need a different perspective.
- Fusing two ideas together
- Do something better that already exists
- Do something unique (only for the truly enlightened individual)
Following these four techniques however is only part of the story, the next part if perhaps more crucial, "failing fast". Most of the ideas created are not going to be great, this is why we need to test out the concept as fast as possible (using the lean philosophy). The quicker we can figure out an idea doesn’t work the quicker we can get back to the initial stage of creating an idea.
No matter what people tell you, words and ideas can change the world. - Robin WIlliams
Tip - The first idea I created was tested out using one of Reddit's subreddit, I posted my idea into the relevant group to garner feedback. With the huge user base I managed to work out that there had been a previous failed attempt, some people were interested, other not so much. Be sure to take this feedback with a pinch of salt, it might not be reflective of the user base you are targeting, but it’s a good starting point.
Having gone through the above process I decided to create a social media website that incorporates religion into the fold. The site will help bring together people, scholars of a certain religion (along with research material) and institutions. I'm fusing what already exists!
Considering 84% of the world follows some sort of religion, the protentional user base is huge, and let's face it everyone's on some sort of social media site. The sites intention is to promote discussion and being together the people who have theological knowledge with those that don’t. Currently this process exists (and has existed for some time) but in a fashion that has lasted for centuries, i.e. going out to a religious institution in person.
As a final note I wanted to share some crazy ideas that have actually worked in the past, anyone remember the million dollar homepage? http://www.dailyblogtips.com/10-crazy-online-ideas-that-actually-worked/
This is a quick guide on how to split unit tests into different categories to decrease the time it takes for your CI build to run. The categories can be used to distinguish different areas of your tests to break down the CI Builds (typically used to run different categories in parallel) or to separate slow running tests into a separate build, all in the aim of speeding up the feedback cycle for developers.Learn More
Last year I was placed in a situation where I had to migrate from a legacy platform (and I mean legacy) developed in Java with a MySQL database backend to an existing .Net, SQL server stack. The project lasted in the region of one years with a team of roughly 8 developers (mixture of both .NET and Java). Having undergone the migration there were a couple of key findings/learnings that I thought were useful which could have helped greatly.Learn More
Security is becoming more front and center for developers as large organizations such as Sony, Ebay and even our NHS are being hacked. Having looked on the internet for a one stop guide on what a developer should do I relized it didnt exist! So I decided to write up my own complete guide on mitigation steps and best practices .NET developers should take. Please feel free to comment on anything I might have missed.Learn More
Recently I have been grinding away on my work Laptop that’s roughly 3 years old! It’s served me faithfully with its I5 processor and recently upgraded (4 to 8) gig ram. However as the updates pile on I’m finding its load times continually increase with every month that passes by. This got me questioning what the effect is in terms of productivity throughout the year so I decided to do some OCD math.
Types of slowness per day:
Opening a program – Load Time: 15 Seconds
Closing programs due to low memory – 1 Minute
Computer died – 6 Minutes Build Time/Opening solution – 10 Seconds
Total : 7 Minutes and 25 Seconds (445 Seconds) per day (lets say we get one a day on average).
Cost of slowness
365 days a year * 445 total seconds = 162425 seconds in a year
(162425 / 60 ) / 60 = 45 Hours of wasted time
For a senior developer (50k salary) that works 8 hours a day
45 Hours / 8 working Hours = 5.6 days ( 50,000 salary / 365 days in a year ) * 5.6 lost days = £767 down the toilet + loss of productivity and a degradation of mentality!
Moral of the story, always invest in the long term.
Perhaps we should create a minisite to to calculate this, print it out and forward the email string away to the manager.
Recently I have been put in a position where I am responsible for a team of developers and this got me thinking…What makes a good team lead? So I decided to scour the internet and make some of my own points, here they are:
- When things go bad be prepared to take the heat and resolve the problem. As with all teams mistakes are bound to happen, it’s just a matter of time! But what makes a good lead is someone who can stay calm resolve the problem systematically and then most importantly learn the lesson (ensure this is also communicated to the team). It’s quite easily to also play the blame game, but I think this is destructive in nurturing a team spirit and bad for confidence levels.
- Lunching together is a great way to get your team to know each other (Create a Lunch Bunch). Socialising between team members is a great way to boost communication in the team and fosters a “I got your back” mentality. Admittedly this won’t work for everyone as some people bring in homemade sandwiches, or prefer to lunch alone. But the ones that do tag along become great team players.
- Be willing to educate team members. As new developers join the team it will be imperative to train the new member. Personally I think this should always be done by the team lead and perhaps assisted by another dev. This allows the lead to gain an understanding of ability’s and where they can be improved. I also believe it’s important to peer program and walk through all aspects of code/infrastructure rather than pointing to a wiki and providing links.
- Protecting the team from interruptions and distractions. Currently in our team we work in two week sprint cycles. Previously we have had situations where by people external to the team have asked a developer directly to work on a body of work immediately. This in my mind is a big no no! It upsets the flow of the team, throws the sprint schedule out of line especially when the task has hidden complexity (usually uncovered during a scoring session). All work should be channelled through a scrum master, or product owner and scored before its worked on. When the task is added to the sprint another task with equal complexity should be removed.
- Understand the bigger picture. It’s important for a lead to continually asses where improvements can be made to process, code, infrastructure and personal development for the team. For the developers in the team this can sometimes be something out of mind as their main focus is around completing tasks, so the lead should always have a to-do list and push to get these scheduled within sprints. These improvements can also lead to a more relaxed and confident team.
- Dish out the credit where and when it is due. Just say “good job” every now and then…
- Be transparent in terms of communication. Filter down information that’s coming from above. Being informed will allow yout team to be prepared for changes.
- Hire the right people. Personality in my opinion trumps technical skills when hiring. It’s important to hire someone who can work within the team without clashing.
There comes a time in all developers’ life when he gets taken down by life’s most annoying disease the flu. I’m actually going through this right now, and I noticed every time I come down with the runny nose I’m always faced with the same question...Learn More
Recently I had a discussion with some of the developers at work about our time at university, more specifically about what modules we studied that turned out to be mostly useless. Some of the guys mentioned assembly language, others about programming languages that have since become as extinct as the dinosaurs. Out of the list one subject stood a cut above the rest and brought out shared smiles across the room... Unified Modelling Language (UML).
During my time at university I remember meticulously creating UML diagrams to fully describe what I needed to create in the next phase of development (in those days waterfall was the first methodology we learnt).
Another use of UML diagrams is on-going documentation. In its usual form this is a model residing on a case tool. The idea is that keeping this documentation helps people work on the system. In practice it often doesn't help at all. – Martin Fowler
Little did I know that once I was out in the real world and with agile being all the rage, most companies work on the basis of having as little documentation as possible. Some would even say documentation is counterproductive to working in an agile environment.
So if this is the case why are university’s putting so much emphasis on UML? In my opinion it’s all down to cost. UML is fairly straight forward to learn and in turn especially since it’s all done on paper its straight forward to teach. This is a bit of a shame considering documentation takes up roughly 2% of my time at work throughout a year. Personally it would have been more useful to learn how to setup environments, deployment process, or simply more programming languages. Problem is this required licencing!
Don’t get me wrong UML does have some uses if the documents produced are actually looked at and updated regularly. However the situation in which the need arises is rare, especially in smaller companies where a team’s development output can be greatly reduced if time is spent documenting.
Today good development practices encourage creating self-expressive code, if you require comments to describe what’s happening perhaps you should start refactoring to make it more self-explanatory. For new starters learning a system should also be supplemented by shoulder surfing and peer programming sessions. Proper handover should also be organised to ensure expertise’s on the project is maintained is maintained within the team.
So you happen to be a student reading this, learn UML to get the marks but remember and keep in mind, it’s not going to be your most important skill.
I thought I should begin this blog with a few words on what I hope to achieve. I started creating this website because I wanted to create a space where I could post/catalogue interesting things I found or learned whilst working as a software developer. I hope to not just blog about software development, best practices or cool code snippets, but also look into some of the other “soft skills” a developer might need. In my opinion being a good software developer is only half the story, the other half is all about getting along with co-workers above and below you. Learning to communicate with non-technies and tenaciously working around the political minefield that we can commonly find in the office.