I won’t become available for consulting again for new customers until August 2019 at the earliest. But feel free to contact me if you just need some advice or want to discuss future possibilities!
A father and son is cooking ham. Every time they do this, the father cuts a chunk off each side of the ham before it goes into the pan.
The son asks why they perform this ritual. Dad responds: “I don’t know. Grandfather is a good cook and he always does this, so I just mimic him. I’m sure it improves the recipe in some way.”
The next time Grandfather visits, they ask him about that ham cutting routine.
“Son, grandson. I don’t do that anymore. The only reason I sliced bits off was to make the ham fit. My old cooking pan was too small.”
The daily standup ritual
We have rituals in software development as well. One of them is the daily standup meeting. Continue reading “Programmer Friday: Do you need daily standup meetings?”
Some level of documentation is necessary in software projects.
We like to say that “the code should speak for itself” and “docs always get outdated anyway”. Both of these arguments are valid, but they should not be an excuse to drop documentation altogether.
Having some documentation in place both:
A) makes it easier to onboard new colleagues,
B) gives you checklists for critical tasks, and
C) makes it easier to get back up to speed again if you’ve been away from the project.
At a minimum, I expect to see the following points covered in Android README files:
I have been working as an independent consultant for a few years now.
Sometimes I talk to others who are considering going the same route. I now have a more or less standard list of advice that I send to them. I’m turning it into this blog post, so I can simply point here next time.
When you build software, it’s easy to get wrapped up in the wrong details or to get ahead of yourself.
Programmers sometimes optimize code prematurely. Or we apply unnecessary patterns, structures and frameworks. This makes our work more complex than it needs to be.
Newer programmers seem to fall into this trap more, but experienced people also get things mixed up occasionally. I certainly do. So: one thing at a time. Continue reading “Programmer Friday: Make it work, make it right, make it fast”
Sometimes you, the Android developer, will work with designers who have the time and knowledge to think of everything. They create complete, detailed designs for every screen and interaction. They cover both web, iOS and Android. They regularly use both Android and iOS themselves. They understand the strengths and conventions of each platform.
These projects are delightful. Unfortunately, all projects are not like this.
I am not the most experienced teacher in my circle, but I have taught some technical classes, courses and workshops in my day — some of them for pay.
Here are some principles and techniques which have worked for me.
Opening screens from other screens in Android apps is straight forward: create an Intent object, stuff some parameters into it, use it to launch the other Activity, and dig out the passed parameters at the other end.
Unfortunately, if you blindly follow Googles standard examples of how to do this, you will end up sprinkling potential bugs around your codebase. Let’s look at how to tighten it up a bit.
I am available for consulting/contracting again in Q1 2018: get in touch!
EDIT: I am booked again, until Q3 2018. However: feel free to contact me if you want to discuss future possibilities!