by Martin Mazur
For us tretton37 knowledge and knowledge sharing has always been top priority. Our business model hinges on sharing knowledge, not only with our clients but also with the community and each other. This makes experimenting with different ways of learning key to our success.
As we have grown we have also recognized that what once was easy — satisfying everyone’s knowledge thirst — has grown more complicated. We recognized that not everyone accumulates knowledge in the same way and what might work for a certain individual is pure hell for another.
This is why we decided to launch the Ninja Budget last year — simply put this is a part of the company’s knowledge budget distributed and put in every employees hands to leverage the knowledge activity that they think will give them the best personal growth.
Ninja Budget was a great step towards autonomy, and this year we wanted to see if we could take it even further. In January we complemented the budget with time meaning that not only does everyone have money to spend on knowledge they now also have paid time to use for developing themselves.
In order to facilitate this and still maintain a sense of us learning together we have a concept called Tribes. The simplest way to view a Tribe is as an internal user group or meet-up; it’s a way to create structure in the autonomy.
We have Tribes formed around single events such as such as JSConf, SharePoint Evolution and BuildStuff. We also have Tribes focusing on modern technology such as machine learning, virtual reality and not one but two different IoT tribes.
I myself recently started a Tribe focused on learning from other programming languages and we are currently exploring Elixir. I am really excited to see what other things can grow from this – the best things start at the grass roots.
by Örjan Sjöholm
We love Knowledge Sharing! However, going to conferences like Leetspeak isn’t part of our daily work. Code crunches and weekend hackathons are nice activities but they just aren’t feasible for everyone.
How can we keep ourselves up-to-date with the latest observations in our field, during an ordinary week?
We can read blog posts or books, watch screencasts from sites like Tekpub, help other developers at Stackoverflow, or join an OSS project.
All these activities require our spare time or sanctioned knowledge development, so how can we make some room for knowledge sharing within working hours?
Together with our teammates, we can combine a lunch with watching a recorded seminar or talking about new findings. Hopefully we’ll continue to discuss the topic and maybe adapt some of the new things we have learned.
12:00 the 15th of May we’re hosting a Global Code Lunch at our customers’ sites. The idea is to inspire people to search for knowledge together, not only in their team but together with the whole community. So if you find this interesting, join us and tweet your findings with the hashtag #code-lunch
by Martin Mazur
I find that people are preoccupied with history. Always looking back and referencing the past to make decisions about the future. One important fact to remember is that it is just that – history. What I mean by this is that the events we are reflecting on occurred in a context which is very different from our current situation. The processes we wrote, the work we did, the technology we used has eventually become stale. Everything has a shelf life simply because time moves forward and the context changes.
Don’t get me wrong, we need to learn from our past, especially our past mistakes. You can learn from history and use it to come up with new ideas, not just re-apply the old ones. Even if something had a certain outcome a year ago, the context may be radically different today and that will make the outcome radically different. Basically you have to respect history when creating your future but you shouldn’t obsess about it.
Working like this is a scary idea for most. It’s scary because we are afraid of the unknown, and the future is unknown territory. I think this is one of the reasons we try to project the past onto the future. We try to minimize variations, completely ignoring that we have a huge variable called ‘the world’ which we can’t control.
Here at tretton37 we understand this, and that’s why it’s so important for us to continue questioning and re-evaluating our approach and ideas – not falling into the trap of “That’s how it’s always been”. With this in mind, we explicitly chose “Challenge the World” as one of our core values. By challenging notions of what we can and can’t do, we continue improving and innovating ourselves. It allows us to try new things and uncover new ways of nurturing people, teams, software and business.
I’m not saying that we should question everything all the time. I’m saying that we need to understand the “Why” and “Why not” of the things we do and ideas we have. If either of those reasons change or we don’t agree with them, we have justification in challenging that idea. Since we carefully evaluate the reasons behind our ideas, we feel secure with this type of controlled innovation.
We feel confident in calling our company tretton37 and ourselves ninjas. Because why shouldn’t we? Some may say we don’t take our work seriously but our opinion is that being serious and boring are two separate things. Historically they go hand in hand, but why not separate them? Can’t we have a bit of fun while developing serious software? We take our profession very seriously – we just don’t feel that we have to be boring in order to do so.
It was also quite a leap of faith for us to create a high quality and affordable conference. When we couldn’t see the reason for why there shouldn’t be one, we challenged the notion of the huge, classic conferences. Does it have to be expensive? Can we make it affordable, awesome and high quality? We thought we could and we think that we succeeded.
These are only some examples of how we’ve challenged historical notions in our industry and we are by no means intending to stop.
by Joel Sannerstedt
Last week, three of us from tretton37 in Lund had the opportunity to, along with two guys from a telecom company in Copenhagen, attend Dan North’s two-day masterclass, Faster Software Delivery. The class was held at Foo Café in Malmö which is an independent meeting place for people within the IT industry in the Malmö/Lund area in the south of Sweden. Foo Café is located in Media Evolution City, which is a nice place for this kind of event. In addition to that, the coffee and food served were great. (On a side note, it was really interesting to see six software guys trying to set up the AV in a meeting room)
Listening to Dan North for two days was a really positive experience. We had great discussions during the course and we received a lot of very good and useful information with many a-ha moments.
Many of the discussions spun around Dan’s Patterns of Effective Delivery, how to create and deliver software faster. One major theme in this, is what Dan calls unpacking the agile hype. Agile has been very effective in comparison to development in the pre-Agile era, but what we need to do now in order to take the next step, is to challenge these practices. Instead of using each technique and adapt each practice, we need to ask ourselves, what are we optimizing for? What is it we’re trying to achieve by using this specific technique? And what could be doing instead? During the course, each question was discussed thoroughly and different answers proposed. Trying to retell these are well out of the scope for this post, but there are a few talks by Dan on the subject available on the interwebz.
// Joel, Per, Stefan
by Peter Ekerot
We at tretton37 never do anything half arsed. We’re into SharePoint and we mean it. We are ninjas, even on SharePoint!
I firmly believe that SharePoint is truly ninja. What other system is awesome for collaboration straight out of the box, useful as a content management tool, has document versioning and workflows, can calculate large spreadsheets, batch convert documents, or integrate with obscure backend systems? SharePoint can do all of that and much more.
SharePoint can exist on its own servers, be it real ones or virtual but it can also exist at Microsoft Data centers; courtesy of SharePoint Online.
SharePoint has evolved over the course of more than ten years. Many of the core concepts that where there from the beginning are still there. Some of the refinements in the latest installment are an enhanced enterprise search (especially with FAST), a rather impressive “My Site”, and a very useful taxonomy (tagging) system.
SharePoint is also a large and extensive development platform. It can solve business problems, and a rather full range of business problems at that.
However, there are some dark clouds in the otherwise blue skies of SharePoint. It does not excel as a content management platform for public-facing internet sites without some deep thinking and special implementation details. It is not very mobile or tablet friendly out of the box, although some of the recent cumulative updates have addressed some of the problems, among other things.
So, where is the ninja stuff?
SharePoint as a development platform is huge. The foundation is .NET Framework 3.5, which might not be the latest and greatest but does the job. There’s Business Connectivity Services (BCS) to connect to any other system imaginable, either using WCF services or custom code – giving great integration possibilities. With the Client Script Object Model (CSOM) and custom tools like SPServices, one can build really nice, productive and fluid user interfaces on top of SharePoint.
As with any platform one needs to work with the grain of the fabric when developing SharePoint. What’s different from other web technologies or frameworks like ASP.NET MVC is the sheer size of the fabric we have to work with and the rather steep learning curve. Building properly on top of SharePoint requires a very good understanding of how the platform works and what parts to use for what purpose, and believe me; there are many parts. Beyond that developer tooling may sometimes be tedious at best. For instance one needs a full server installation just for development, which makes development start-up time for new projects significantly longer than with other web technologies.
The ninja part comes with deep experience in developing for SharePoint, choosing the right approach for the problem, applying standard features or custom development. A problem can often be solved in one of many different ways, it takes a ninja to know the right one.
And this is just for developing solutions. There’s room for much more under the SharePoint flag; Configuration management, Infrastructure, Integration, Security and more.
On the topic of SharePoint and ninja or not, I think the following piece by Mark Rackley is explaining it rather well, especially the twitter quote:
“@mrackley: Here’s an interesting question. Is it possible to be a “Junior Architect” in SharePoint? I think by its nature it’s a senior position.”
“@cmcnulty2000: I once met a junior surgeon. Didnt use him though. (my favorite response)”
There are so many facets of SharePoint solutions and development that a single person can’t really know it all (except some people – but a select few have cleared that certification).
Want to know more? Send me an e-mail or leave a comment
About this blog
We at tretton37 believe in having a strong company culture that promotes craftsmanship, professionalism and knowledge sharing.
We want to use this blog to share what we know and give everyone insight into our thoughts.
Here is the RSS link for this blog:
- May 2015
- April 2015
- March 2015
- November 2014
- October 2014
- September 2014
- August 2014
- June 2014
- May 2014
- April 2014
- March 2014
- February 2014
- January 2014
- October 2013
- July 2013
- May 2013
- April 2013
- February 2013
- November 2012
- October 2012
- September 2012
- August 2012
- May 2012
- April 2012
- January 2012
- December 2011
- November 2011
- September 2011
- June 2011
- May 2011
- April 2011
- March 2011
- February 2011
- January 2011
- November 2010
- October 2010
- August 2010
- July 2010