Find out about me on a professional level, pick out a book from my recommended reading section or read one of my blog entries.
If you hit a technical limitation in software intended for use by a person ask yourself if you should be solving the technical problem or changing the user experience and design so it's actually usable. Usually, by giving the user a better experience you also eliminate the need to solve that technical problem.
Here are a few questions you can use to get the wheel turning:
What is the user trying to do or what information are they most interested in?
Do you currently have the data needed to give them a customised experience (if not can you get it)?
When you use the software/system are you shown information or intermediate steps that you really don't care about?
You hear the word Agile thrown around a lot these days, people use it as a catch all term without really understanding what's necessary to truly be Agile. You see companies advertising they're doing Agile using words like scrum, sprint, user stories, and kanban. Someone in management hears they should be doing Agile and they hire an Agile expert or a Scrum master who comes in and tells them they need to do daily meetings standing up, write their requirements in terms of user stories, somewhere in there a chicken and pig analogy will come up to illustrate peoples new roles then they're told to stop wasting time doing design and just deliver features. A lot of these things are good when used in the right scenario after the proper foundation for a truly agile process is in place and yet the majority of the time the foundation is completely left out. Whoever brought in the consultant to get the department doing Agile will pat themselves on the back and if they're lucky they will see some improvement just long enough to get a big raise or bonus in their annual review. It won't take long before the features being developed take a bit longer than the 2 week sprint and every release will get reverted because of bugs that weren't found before the release went out. The daily scrum will go from a quick meeting to discuss blocking issues to a drawn out one that's mostly just a status update which can clearly be seen on the kanban board. This will build up until eventually the company falls back into old habits and claims this Agile thing doesn't work, or worse continues to claim they are still Agile.
The foundation of Agile software development is Test Driven Development, Continuous Integration and Continuous Deployment. Without these 3 things in place you're not being or doing Agile you're building a Fragile system that will eventually fall apart.
What is mobile first?
Put simply Mobile First means you start designing for the smallest, least capable device your customer may be using. Whether
you're starting a completely new project or adding a new feature to an existing site you start with mobile. Once you have the
experience figured out on the smallest, least capable device you plan on supporting you move up from there, this normally
means phone -> tablet -> laptop/desktop. I normally take this one step further and design a "Basic" site that utilizes
the bare minimum CSS and no JavaScript at all so you end up with something like Basic -> Mobile -> Tablet -> PC.
I've found this ensures that no matter what device, connection speed or any other factor that I haven't considered comes up,
the basic functionality always works even if it doesn't look so great.
I've been trying to evangelize Test Driven Development (TDD) for quite a while now and come to the conclusion that in order to really appreciate it you need to fully commit to doing it properly. It won't really hit you the first day, first week and may take more than a month but at some point you will hit that moment when it just feels wrong to write code without first writing a test for it.