The world of SharePoint development has changed almost completely in just a few years: we’ve seldom seen such a radical platform change happen so fast. What were your experiences? How did you see those changes?
Moving from SharePoint on-prem development to SharePoint Online development was indeed a huge change. For example, if we think about web parts, you’d have a file for the user interface and then another file for the backend code. These days, with the SharePoint Framework model, you only have the client-side code, and if you want to do anything on the backend, you need to set up your server-side code separately in Azure and call it from the web part. As a traditional SharePoint developer, you might think at first that this is a lot of hassle, but I think it’s a better model in the long run, because it automatically makes your solution a lot more modular.
Another thing that’s changed with the modern sites is that you can’t create things like master pages and page layouts anymore. These days, you have more controlled options for customising the page layout, which encourages people to work with the out-of-the-box features first, getting as far as possible that way, and then only after that to evaluate whether a feature is so important that it merits being implemented as a custom SharePoint Framework extension. I think this is good because it reduces both the implementation and the maintenance costs for the customer.
Why is SharePoint Framework good? Or are you still using other deployment techniques for SharePoint Online?
Good code is easily readable and maintainable by people other than the person who originally wrote it. Keep it as modular as possible and have unified naming conventions. Don’t write code for yourself; write it for a future junior developer who will one day come and maintain your solution, because hopefully by then you’ll have moved on to something else.
What is good code?
Good code is easily readable and maintainable by people other than the person who originally wrote it. Keep it as modular as possible and have unified naming conventions. Don’t write code for yourself; write it for a future junior developer who will one day come and maintain your solution, because hopefully by then you’ll have moved on to something else. I know a lot of people say ‘Code documents itself’ but if you have a complex scenario and can save a lot of someone else’s time by writing that tiny little comment, just do it. Good code is also optimised from an execution point of view, so users don’t have to wait longer than is necessary. However, quite often you need to find a balance between optimal execution time, readability and how much time you can spend writing that piece of code. Optimise code where it matters. The implementation should also match the requirements and be secure. And, of course, the code should also be bug-free – though you never know if your code has bugs or not until you find one.
Why are there so many good SharePoint developers in Finland? Is it the climate?
Hah, yes, definitely! We don’t have anything better to do during those long, cold winter nights than go home and do some proper SharePoint on-prem development, preferably on an old MOSS farm. But, honestly, I don’t know. Are there? I haven’t seen any statistics. Let’s say you’re right and speculate. Finland seems to be a little bit ahead compared to many other countries when it comes to adapting new technologies, so we might be able to accumulate more knowledge earlier on. Having only 5.5 million people, our IT circles are quite small, so everyone pretty much knows each other – and we’re not afraid to say ‘I don’t know’, to make mistakes (as long as we learn from them) and ask for help. We share our knowledge, learn from each other and become better together. And a bit of Finnish ‘sisu’ sometimes comes in handy when troubleshooting SharePoint issues. 😉
Did you like this article? Are you interested in this topic? Would you like to share your knowledge and experience with the authors and other readers? Our #communityrocks group on Facebook is bringing everyone involved together: authors, editors and readers. Join us in sharing knowledge, asking questions and making suggestions. We would like to hear from you!
Join us on Facebook
In this article you will learn what the potentials of the PnP Provisioning Engine are in the fields of provisioning resources in Microsoft Teams, within the context of Microsoft 365 and SharePoint Online.
With Office 365 and the flat architecture of modern SharePoint Online sites, there’s a little bit more to plan for the intranet landing page.
The aim has never been to get as many people as possible to use a product (consumption), but rather enable employees to deliver their tasks efficiently, at the same time building and developing new skills.