It's nearly impossible to keep up with technology today especially when there are so many competing technologies. I've chosen to specialize in the Microsoft technology stack, partly due to their excellent development tools and partly due to their willingness to acknowledge and support the use of open source technologies within their tools.
Sometimes I find a tool or a widget that nearly meets my needs, but not quite, so I modify it to make it work exactly how I need it to. That's one of the benefits of using open-source tools when appropriate, and also one of the benefits of my experience and education. If I need functionality that doesn't exist, I can build it myself.
When gathering requirements, I ask a lot of clarifying questions so I can get a solid development plan in place. With a good plan, I work quickly.
I often have suggestions that will make a user interface more intuitive, and always look for things that would be confusing to a user, and recommend alternatives. What we end up with is an intuitive user interface that needs little or no instructions for the user.
I have the ability to convey technical ideas and concepts in everyday language, effectively bridging the gap between business folks and technical folks. This comes in handy both when working on a team, and just working with non-tech-savvy customers. The nice thing is that you don't have to understand the technology that makes the application do what you want it to do. You just have to know what you like and what you don't. I take care of the rest.
My role is to understand how your business works; how you do your tasks. With that information, I can help come up with logic and interfaces that will help you accomplish your goals.
My role is to put together plans to make all of the parts of your system work together, including fault tolerance and logging, using the latest technologies. When architecting a solution, I don't just look at the here and now, but think about the future. How will this application stand a year from now? How about beyond that? Will the technologies still be valid? What kind of maintenance will need to be done? Answering these questions is part of choosing the right tools for the job, and helps to avoid surprises down the line.
My role is to make your business processes easier to manage. The goal may be to streamline and simplify your redundant tasks. If you have processes that you do over and over again, and those processes have predictable, repeatable steps then I can help to automate those. With those tasks automated, you can concentrate on more important things. You can concentrate on your business. If the goal is to produce an application, either internal to your company or for public use, I can help you there too.
Once requirements are known, I build a detailed work breakdown structure so I can give accurate, realistic time estimates and create project milestones. You'll know ahead of time when you'll be able to test new functionality. I love meeting deadlines.
I always code with maintainability in mind. I've inherited projects from other developers that have poorly written code, riddled with dead code (code that does nothing or never gets called), or is just nonsensical...and that makes the code terribly difficult to debug, fix, or enhance. Coding with maintainability in mind means producing code that any other developer can easily read and know what's happening, so they can make modifications or enhancements easily.
In many cases, a piece of functionality will be used in more than one place in the application. Making that piece modular so it can be easily reused in other places without duplicating the code is what I strive to do.
Application crashes (unhandled errors) are really unacceptable in a live application. Program errors due to faulty logic are the developer's fault. Uncaught errors due to a user providing bad input are the developer's fault. Errors due to a communication failure with another piece of software or hardware are the developer's fault. Anticipating what these things are that might cause errors is the developer's responsibility, and protecting against them, or handling them gracefully when they do happen is the developer's responsibility. That's what I like to call bullet-proof coding. Unanticipated things happen. I believe in being prepared for those things. I politely let the user know that something has gone wrong, and log enough information about the error so the developer can diagnose and fix the issue.
© Viceryl 2017 - Tom Puleo