No one is irreplaceable, and that is a fact. Teams often find ways to overcome the loss of staff, even creatively. Some losses hurt more than others. One key factor is institutional knowledge.
I personally believe cut-and-paste coding can be one of the sloppiest and least reliable ways of developing a product. Consider the source.
DRM is a sticky issue. I found this out the hard way recently when my Keurig machine died.
I am a big fan of learning moments. In business, some learning moments come at a cost. Some mistakes are easier to forgive than others. I still believe in exercising as much patience as possible to allow people to learn.
Drupal is definitely a framework enterprises can leverage. I think few would argue this. But, the term open source freaks out a lot of people. What it boils down to is how to best leverage this framework. This means that we as a community need to adopt best practices in how Drupal is used.
I was recently asked about what separates my company from others I have worked in the past. What immediately came to mind was the relationship with my team, the work we do, and the sheer talent. Those elements alone still make me get up in the morning.
Estimations suck. Seriously. To do estimations properly, it requires significant analysis and a sound grip on the full project scope. It's hard. There are always unknown complexities that creep up. Estimations set expectations and impose risk when complexity is not identified.
Recently, it hit me that there are actually benefits to having a short term memory. I don't think this is broadly applicable. In fact, I think there are more instances in which you do not want to have a short term memory. Allow me to explain...
Companies are very bottom line focused. Even after a high level scope of work is determined, the most appealing bids often are on the lower end. Even if some form of a deliverable can be achieved in a given number of hours, it often does not yield the correct one.
If you're doing Drupal development, having a local sandbox is a necessity. Why? No one should be making untested changes on a production or staging server.
In a previous job, I had a boss that I really admired. He's near the end of his career and his experience had made him wise. He was humble, but would chime in as needed. One of my favorites was his ability to bust out short one-liners that would hit the nail on the head.
Nodes are the unquestioned most robust data structure within Drupal. It has widely adopted integration, e.g. Views, Features, Context, Rules, etc that make the Node a popular Drupal entity for countless use cases.
Projects are risky. Specifications are nearly impossible to define on most projects due to technical or communication gaps. This is the age old challenge many people fight.
Bad projects are toxic.
While most staff within a company focus on the bottom line, the bottom line is no guarantee of project success. It's impossible to look in your crystal ball and make this call before a project begins. Hindsight is 20/20, right?
At the heart of Agile is flexibility. This is designed into sprints that are intended to account for changes rolled into subsequent sprints.
Push aside the user stories, contracts, and legalities. When push comes to shove, the developer delivers the goods. In my mind, there is huge risk to a project with the role of a developer.
Peter Nixey describes good developers as both technology proficient and hard working in his blog post. His concept of "simplicity" is worth noting.
The Migrate module is, hands down, the defacto way to migrate content in Drupal. The only knock against it, is the learning curve. All good things come to those who take the time and learn it.
As organizations evolve, traditional metrics and philosophies are being thrown out the window to further organizations. Such factors include efficacy, employee satisfaction/ownership, innovation, etc.
Personally, I love bagels. The pinnacle of all bagels is the toasted everything bagel with plain cream cheese.
I reserve the right to update this over time, but let this serve as the Bergstein Metrics of Bagelology.
1. Seeding Amount
This is a topic I have grown all too familiar with, as this is my thesis topic for my master's degree. I thought I'd share some basics to set the stage in this area of work.
Standing in a Boston hotel room, I went to put my room key in my sport coat pocket and found something that gave me pause. It was a sign.
The Coder module (http://drupal.org/project/coder) is well known for assisting developers in producing code up to snuff with the community defined standards. Such standards have been integral in helping the community grow in a consistent manner.
Much focus has been paid to Matt Niskanen or Simon Depres finding new towns. This is the most likely scenario, as Niskanen's youth and recent good play has surely garnered focus. His trade may be more likely, as Depres came to camp over weight.
Drupal is a complex and robust system. Due to all of the processing required to bootstrap Drupal, enabled modules, enabled themes, and page-specific rendering, one can imagine performance becomes a major concern.
My previous post outlined my exploration in text editors. But, there are several other tools that revolutionized my ability to do my job.
To innovate, you often have to risk getting out of your comfort zone. The last several years, I have had varied needs which have required me to evaluate new text editors that offer more robust functionality.
What happens when there are a lack of open problems? On the surface, it seems to make it more difficult to have impactful contributions. I just think it requires you to think outside of the box.
Scale and performance are major issues for high traffic websites. The design of the Drupal system poses many challenges to building a distributed system that can support load balancing.
Apple's release of new iPhones and iOS7 has been criticized for what analysts claim is a lack of innovation. Such things have been prevalent for years in Operating Systems, productivity software, tablets/mobile phones, etc.
We've all had to deal with difficult people at work. It doesn't get easier when the difficult people are those you serve.
You've heard it all before. "The old programmer did this and it's crap" or "This person used this tool and it's no good". It's the age old grudge match between the old and the new. And, it doesn't help anyone move forward.
I recently read this article: http://bryanbraun.com/2013/09/21/please-stop-stewing-and-start-blogging-about-drupal
If you spent hours solving a problem, what is the likelihood you will remember exactly what you did the next time it comes around? Don't solve the same problem twice. Find a way to automate routine tasks so you can focus on other challenges. What are some strategies used?
Well... here goes nothing. I've always wanted a way to share the things I've learned.
Good programmers learn from their mistakes. The best programmers then share the love.
I welcome your thoughts and encourage you to engage in conversation through comments. Thanks for visiting.