In enterprise software development, one type of project stands out from most others – a Proof of Concept. At times, you may come across planning or technical questions that have far-reaching consequences and no clear or easy answer. In these cases, it can be a good idea to spend a small amount of time and resources to build either a single example project or even a series of similar projects using various languages or libraries to determine what works and what does not. These kinds of projects are called Proof of Concepts (or POCs).
Mastering Organization: Developer/Consultant’s Guide
In the fast-paced world of software development and consulting, staying organized isn’t just a luxury; it’s a necessity. Here are some tips from my experience as a software developer, but they should help anyone, developer or otherwise.
The Mythical Person Month: A Lesson On Managing Expectations & Meeting Deadlines
One of my favorite things about the life journey that I find myself on is that I’m always learning. Every. Single. Day.
Some days I learn something new… most days I learn something new, actually. But then there are the days when I am reminded of something I learned years ago but have somehow forgotten for a time.
The Mythical Person Month is one such topic. It is a distinct and important lesson that I have learned many times now it seems.
Writing Quality Code: Practicing “Make It Work, Make It Right, Make It Fast”
Kent Beck, a software engineer famous enough to have his own Wikipedia page, is quoted as saying, “Make it work, make it right, make it fast.” A quick web search will show you several pages discussing this quote, some in great detail.
So, I’ll write another, and hopefully, I’ll provide two things to build on the existing literature. First, I’d like to put this concept in front of some programmers that might not have heard it, or if they have, haven’t taken it to heart.
Second, I’ll provide my own philosophy on the subject. Maybe it will different enough that you’ll get something new from it. I do have a slightly different take on it. Although I don’t want anyone to change the quote, maybe we can instead think of it as, “Solve the problem, make it maintainable, and make it perform.”
Effective Engineer Onboarding: Removing Speed Bumps for a Growing Team
I imagine that most engineers have endured at least one painful onboarding experience. Every person I’ve asked has given me a unique example, from relying on piles of outdated notes to being stuck in some sort of task-less limbo and forgotten by the rest of the team. What should be your first impression of a new team can turn into a nightmare if that process isn’t handled properly.
In this post, I will describe some common themes from these bad experiences, as well as how a team can identify them proactively and work towards a better experience for their next new engineer.