You build a product. Someone else builds a shared lib. You want to use the shared lib in your app for its apparent utility. There come new features that the product team wants to adjust and add to your product. The shared lib provides utility that is related to these new features but does not provide these new features per se.
You work every day. It’s a part of life. It’s a good part of life, and you have the power to make it better. Ever since you were young child, you knew what the magic ingredient was: fun!
Culture will emerge after a group of people attempt to solve problems again and again in a certain way. This “way” becomes the culture. If you are deliberate in your choices on how to solve problems, you will be deliberate in creating a culture. Once you have a culture in mind and are working toward it or trying to maintain it, how do you determine how healthy it is? Clay Christensen has a simple question you can ask yourself.
Remember that last time that you spoke at a conference and really felt like you had connected with your audience? You were able to keep them with you for the length of your journey. You felt like they grew and were enlightened with you. There’s a certain magic to that, and there’s also some deliberate thought you can give the experience that will help it happen more often.
Some have surmised that working more will help their team. It may. It may not. It depends. Here’s just one collection of thoughts on how working significantly more than the rest of our team might not help and may actually hinder.
It seems to be a recurring discussion in the companies I have worked for: should we use a codename for this project or not? These are software projects. The codenames are used on things as basic as the repository name or slack channel. Later, they might be used in many other project-related things like the build server configuration. The alternative for a codename is calling the thing exactly what it is. Where’s the fun in that?
An estuary is where the sea meets the river. Here, there is a mix of fresh water and salt water, sediment from the rivers and marine life from the sea. The effects of both sea and river are seen in many ways. It’s a swirl – there’s no upstream or downstream. It’s considered to be one of the most nutrient-rich, productive ecosystems on the planet. So really, who wouldn’t want to make software in an estuary?
Sometimes it seems like we feel everything we produce must be our magnum opus – not just great work, but the great work of our career. Somehow we end up thinking that this thing we’re working on is the final act, the thing that will dwarf all our previous work. The thing that won’t – in fact, shouldn’t – be toppable. We tell ourselves that we’ll forever be judged by this one artifact. Is that the case? Probably not.
Do you ever get home and not remember what you did for the whole day at work? You were always on the move. You were always doing something for someone. Obviously you were a much-valued member of the team to have so much required of you. So then why can’t you remember what you actually did? And if you can’t remember that, surely you can’t remember why you were doing it!
Slack is a fantastic tool. It allows always-on group chat in this spirit of Hipchat or Campfire or your friends’ group text thread that just won’t end. You can create channels, public or private, to suit your purpose. You can gather communities together to talk about specific things. Slack can become an invaluable source of communication and information for you and your teams. Without a bit of management and care, however, it can become a burden that distracts you from the essence of your work.