Managing a product is hard. Ideas come from all angles, many of them have merit and worst of all you don’t generally have enough direct feedback to make an informed decision about which ideas carry the most value.
There is an inherit danger in committing resources toward too many fearures. Time is finite and the team is small. Picking the wrong features means potentially confusing users or failing to attract users in the first place.
The worst part is that picking the wrong features means that you are also not working on the features that users need, compounding the problem by way of temporarily hijaacking development time and diluting the product like a bad domestic beer. …
I have noticed over the course of the last few months that each time I made an online purchase, miraculously advertisements for a related product appeared in my Facebook feed.
Once I didn’t even make a purchase on Amazon but only viewed the product — low and behold that exact product appeared in my Facebook feed.
I am not a conspiracy theorist or a privacy freak but this is getting a little creepy. It feels like there is a constant eye-in-the-sky watching my activities and making suggestions for the benefit of the all almighty economy.
Where is the line? When will the general public feel violated?
I remember a time when the general consensus said that we should not place any person information online including address and credit card numbers. That seems laughable now.
Hikers get into conversations about their travels only to begin a cycle of stories that “one up” each other. Most of these conversations end with an outlandish story from Alaska that cannot be outdone.
Ten years into this experiment, the Cajun Journeymen take on the Alaskan wilderness with an audacious back country adventure. Follow us through the rugged landscape found in Wrangell-St. Elias National Park along the goat trail from Wolverine to Skolai. This is not a trek for the faint of heart. We traversed vast tundra steppes, steep ledges, massive rock fall, high passes and deep canyons. …
Over the past 3 months I have completed a rewrite which converted our application backend from a SQL Server to MongoDB. This is quite a shift in design and thinking. In many ways I was forced to rethink my approach to data storage after many years of SQL Server development. In this series, I will explore my thoughts on the subject.
Joins are a construct that is essentially native to relational databases. Relational databases represent data in 2 dimensional tables (with some exceptions such as XML field support).
On the other hand Mongo is a document data, which supports rich hierarchical data structures. This allows you to embed related data in a single document which can be retrieved in single request. There is no need for a join operation if you are thoughtful about how your document is structured in storage. …
IT projects are difficult, long and arduous. Requirements change, budgets are tight, and deadlines loom like a dark cloud. Sometimes it feels like you are moving mountains to ship the project. It can be quite a grind. For people like us that care about the quality and craft of our work, this can become quite the pressure cooker.
We are very much invested in the success of the project and the success of the business as a whole. To the point where we sacrifice personal/family time and relationships.
Generally the technology nuts and bolts do not present the biggest obstacle. Accumulating context is the real money pit. A lot of time is spent understanding the customer’s business process and how technology can help to streamline that process. …
Data migration can sink your project. It lurks around the edges of your estimation model, hiding deep dark secrets that will only be uncovered at the very end of the project. Nothing could be worse. Discovering that you need to increase the migration schedule 5 fold at the 11th hour can not only derail your project but if it happens too often it might derail your career.
I have learned a few lesson on this topic:
Re-estimate your migration scope of work when there are significant changes in the new application. At the beginning of the project, migration seems easy. …
There are times when I have witness (and participated in) arguments about trade-offs between scope and effort. Sometimes developers tend to push back fairly hard with the perception is that the effort is too high for a particular feature change.
Coders can become downright defensive when you are talking about changing the fundamentals of an application. After all, this is their baby and someone just through it out with the bathwater.
As programmers, we need to remember that software is soft. Meaning that it can be changed and it should be changed to conform to whatever the application requirements dictate. We are not talking about destroying a building to change the wall color. We are talking about changing software to meet new requirements.
By the way, we are paid to make these changes.
Originally published at clintsimon.com on November 9, 2012.
One of the best things that you can do as a developer is to be equal parts lazy and smart. This is an art that can be mastered to great effect. I don’t mean that you should abandon your passion for programming or stop being focused and goal driven. I mean that you should avoid work that is not absolutely necessary. To do that you need to be both lazy and smart in equal parts.
There are pitfalls. Laziness without being smart leads to inaction. Being smart without laziness leads to constantly reinventing the wheel. …
Over the years I have come across software consulting companies in various states. It occurs to me that there must be a finite set of categories that defines the culture of a consultancy. Here’s a few that I have recognized.
The oak tree. This company is rock solid and has been that way for many years. After establishing itself initially, stable but modest growth has lead to a consistency over time. To be successful at this company, you must deeply agree with the culture and value system. This can be a great place to have a long tenure and create long term professional relationship. …