Diversity and inclusion matters have been on the rise lately, and fortunately so. All of these topics are valid and serious issues. We strive to find solutions to some of the ongoing issues. This topic needs to be tackled from multiple angles, however, during this blog, we’ll look at how we can have a positive impact on the process as UX and Service designers.
A quick note on terminology
The acceptance, understanding and embracing of the differences in people including, but not limited to:
– gender, age, race, religion, disability, sexual orientation, and ethnicity.
– personality, education, skills, knowledge, and experience.
Inclusion is a collective of conscious choices to improve a supportive, collaborative and respectful environment. The idea is to increase participation for all employees regardless of the above.
*Diversity and Inclusion
This describes the company’s practices and strategies to boost the diversity and inclusion in the workplace. The aim is not only to be a noble company but, the goal is to achieve a competitive business edge.
What you can do as a designer.
Alrighty, enough talking about intangible concepts, let’s have a look at what we can do as designers to directly impact the diversification of a workplace.
1. Redefinition of masculinity and femininity through design
As designers, we help re-enforce stereotypical thoughts in our user’s mind. Challenge yourself to always think differently about gender roles. Why do Yoga apps always look delicate? Why are some pages still pushing for pink and purple to attract women? Stop designing sports pages with male-oriented linguistics. Choose boundary-pushing imagery, not sometimes but often. Whether it’s a female truck driver or male nurse, always challenge the status quo. However, be aware of pretentiousness, users can see right through that. Have a cohesive and holistic approach to achieve a consistent image of correct redefinition.
2. Discard assumptions and bias from your Design Thinking or UCD process.
Does the nationality of a person really add vital information to your persona or will that build more stereotypical assumptions? Are you covering all shapes and sizes of people in your user research? Thinking constantly about these questions will help prevent any backlash and produce truly inclusive products.
3. Re-evaluate “normal” and “average”.
Over the centuries we have been trained to think that normal equals homogeneity and diverse equals odd. A lack of diversity in traditional and digital media also trumps the development of diverse and inclusive concepts. As designers, we are constantly working closely with these mediums and we are able to redefine normal. Being diverse is normal.
4. Accessibility as a requirement.
Security aside, no doubt that most designers would like to create products that are accessible to everyone. However, most designers find it quite complex to create a product that is truly usable and useful for people that are less able in certain aspects. The reason being ‘working from the bottom down’. In other words, the thought about accessibility is considered at a late stage where further simplification might prove tough. Around 5% of the world is colour-blind, meaning that colour coding should always have an alternative in your design. In other words, do not rely on colour to communicate. In general, the solution to accessible design is simple. Have accessibility analysis as part of every step in the process. This is an extra step but that should be standardised to reach a truly inclusive experience.
5. Place yourself in someone’s else psyche
By placing yourself in some else’s shoes, often you can reveal emotions and needs that you might otherwise overlook. This is the next best approach, other than getting direct user feedback. Let’s look at an ethnicity form example where one had to make a choice from a defined list
What is your ethnicity?
Now let’s think about a person from the Middle East trying to fill in this form, he can either choose Asian as it happens that her/his country is situated in Asia or Other. Neither of those choices defines who that person is or what he identifies as. Such a form will extract false information and will create an un-inclusive experience that will indicate that the system or company has not taken his ethnicity into consideration. An alternative solution could be
What is your ethnicity?
O I Identify my ethnicity as …………………………
O I prefer not to say
This design will give equal importance to all ethnicities as well as a choice to not state ones’ ethnicity if they don’t wish to do so.
As designers, we often underestimate our role in society. Never have we had so much power to create a positive impact in the world. Our designs and products are getting distributed worldwide at a rapid pace. Thinking about the business value for our clients, without a doubt is important, and pairing it with a thoughtful design process to improve lives will transform us from good to great designers!
I count myself as one of those whose quest for getting certified has gotten slightly out of hand. During my 1,5 year stay in Gofore I’ve completed the following certs:
Amazon Web Services (AWS)
- DevOps Engineer – Professional
Google Cloud Platform (GCP)
- Associate Cloud Engineer
- Professional Cloud Architect
This is the story of how this came to be
Chapter 1 – England 932 A.D.
The quest started two years ago, in the fall of 2016. It had become apparent in discussions with my friends and in tech news that AWS Certifications were the hot stuff in IT workplaces. As I was doing the groundwork for the classic “looking for challenges” ie. “looking for what challenges to look for”, I thought that maybe this would be it, and I started looking for resources to learn AWS.
At this point, my dear reader, you might take me as a simpleton, and I cannot prove you otherwise. Sometimes I make decisions on a whim.
I started the task by googling, but found out that I would need a more formal structure for studying. Googling only helps if you know what you are searching for; if you are completely clueless about the subject you only learn dots here and there, with none of them connecting. Luckily after I while I stumbled upon https://acloud.guru and instead of stumbling I started to jog.
In a few months, I managed to get the Solutions Architect Associate followed by Developer Associate a month later. Around this point, I applied to Gofore and after the 2nd round of interviews, I passed the SysOps associate exam. To the surprise of many, I got hired and started as a System Specialist at Gofore on 1.3.2017. I had planned to do the DevOPS professional certification straight away but as my first project was on Openstack I was overwhelmed by the amount of new information and decided to take a timeout on certifications.
Chapter 2 – Witch & Duck test
Summer arrived, quickly followed by fall. A new project arrived and finally with an AWS context. After two months of AWS-labeled elbow grease, I started studying for the DevOps Pro course once again and found it easy compared to 6 months earlier. “I do this stuff every day”, I thought. Two months later I took the exam and passed.
As the year ended, so did the project. Now I now had a positive problem: I had some 20% of my week free from other projects and internal work. At this point, it had become apparent that Azure had taken some foothold in Finland’s cloud scene, and there was lots of talk about utilizing Azure Stack in traditional data centers. I didn’t know anything about Azure, and as our pool of Azure masters was limited and list of certified Azure people non-existent, I told people I was going to do all the Azure Certificates, and also do a helpful how-to for others to do them also. There was lots of rejoicing. Two months later I had done all the three exams required by MCSE and the path I took is nicely documented in our Confluence Wiki.
Chapter 3 – Knights Who Say “Ni!”
In March I started working 100% on projects again. The question of “what about Google” didn’t exactly keep me up at night, but it was still bugging me. My project was running on AWS but as it was a familiar platform by now, I could simultaneously study the Google Cloud Platform (GCP) in my free time without being overwhelmed (again). I started studying GCP the same way I started with Azure and AWS: by studying for the cert exam. Once again I documented everything I read about GCP in Confluence and rated those sources’ usefulness. This work also benefited me when I was reviewing for the exam. Around May, Google announced the Associate Cloud Engineer Beta exam, which I took as a practice exam for the actual Professional exam. I quickly forgot about it as results wouldn’t be announced until later that summer.
Two weeks before the pro exam I ordered myself a Playstation 4 as a prize for passing. I passed, and I could finally unbox the darned thing that had haunted me for the past few days. I also got mail from Google that I had passed my Cloud Engineer exam, which was a pleasant surprise. For the rest of the summer, I spent my free evening time just casually gaming, benefiting no-one.
In October I got a mail from AWS that some of my earlier certifications were going to expire and I decided to do some personal ‘Teemu Selänning‘ (the hockey player who always wanted ‘one more year’ before retirement) and do one more certification (still working on it).
Chapter 4 – End of the Quest
When I started doing certifications it wasn’t “just for the kicks”, it was a move to improve my career. I wanted to work with something that was challenging and hot tech-wise and I saw certifications as a key to that goal. Cloud was (and still is) quite a young technology, and there are no cloud experts with 20 years of experience. If there is a knowledge gap between you and a senior cloud practitioner, it can be caught up.
When I started doing the Azure and GCP certs the communality aspect of it increased my motivation: by being a forerunner in those certs (ideally) others would only have to replicate what I did in order to succeed. I also suffer from impostor syndrome and I don’t think of it as a completely negative thing; if it drives me forward, it can’t be all bad.
Roughly 80% of the time spent on the certifications I did in my own time, and the rest I marked down as “personal development” and it was considered as working time. In Gofore we are allowed (and encouraged) to use 6% of our time on personal development (approx. 1 day per month). I usually study in the evenings when my kids are finally asleep and mark one day of personal development to some random Saturday; to be later used as a flex leave. When my studying was beneficial for the whole Gofore Cloud team, as was the case of creating the “study paths” for Azure and GCP, I knowingly exceeded the 6% limit for the part that benefitted others (documentation).
Doing certifications may not be your thing, but know this: Google sends swag for every certification exam you pass. It is mainly rubbish, but the mug was cool.
Dave Snowden says that human intelligence is especially based on utilizing patterns. “Our ability to link and blend patterns … gives us the ability to adapt to a rapidly changing context and, critically to innovate”. Metaphors, patterns and stories are the most powerful tool of explanation, knowledge transfer and teaching. We have a limited capacity of information processing capability, but it is not the basis of our intelligence. One group of people make decisions purely based on information processing, and they are autistic. Whether you are communicating a feature in a software project, or a marketing vision of a large enterprise, the best way forward is to communicate it as a story or as a metaphor.
A best practice is a method or technique that has been generally accepted as superior to any alternatives because it produces results that are superior to those achieved by other means. You may find best practices for example in agriculture, medical and manufacturing. Software development has its own best practices. Agility, continuous improvement, prioritization, active communication, design patterns, QA and CI/CD. Agile manifesto itself is a list of best practices. For a seasoned expert, these sound like a no-brainer. Well, how on earth do projects still fail?
While working as a Scrum Master, one realizes that while pursuing well-known best practices, the same bad practices keep popping up again and again. These bad practices form a list of common pitfalls, which are called antipatterns or in an Agile context ScrumBut. The antipatterns can be used as-is, but they are most effective when used side by side with the best practices. Work towards the best practices. Work away from the anti-patterns.
Sprint is too short or too long
- Too short a Sprint (less than a week) increases the ratio of bureaucracy beyond an acceptable level. Too long a Sprint (a month or more) makes it hard to react to customer requests and the feedback loop becomes too long.
- The best practice is to keep the Sprint a bit on the short side, so the feedback and correction frequency stays fast.
- Too long a sprint also allows one to create mini waterfalls inside a sprint
- Often is better
Sprint produces nothing working
- Whatever was developed during the Sprint must be running in at least the QA-environment at the end of the Sprint.
- When software is not integrated, tested or deployed during the Sprint, work will overflow to the next Sprint. This means that it is impossible to change direction between the Sprints. One must first pay off the technical debt that has been created in a form of non-functional code. If nothing new works after the Sprint, the speed is 0.
- Often the “almost ready” features require days of work to finish. You can speed up the completion of difficult tasks by having daily status checks. In the most critical situations, the best way is to set up a “war room”, where everybody concentrates only on finishing or fixing a single feature.
- The best practice is to finish the earlier task before starting a new one.
- Stop starting and start finishing
No (real) Product Owner
- The Product Owner prioritizes and clarifies.
- The Product Owner provides a list of the most important Use Cases and a detailed description of each. The task of a Scrum Master is to tell if those features fit into the next Sprint. The less you start, the faster you finish.
- A common malfunction is a customer who wants software to be developed but doesn’t commit to the development process. Either there is no Product Owner, or the person is too busy/doesn’t know the domain/doesn’t have the authority to make decisions. In this situation the Scrum Master should coach the customer; book a weekly meeting with the customer representative where the roadmap is being clarified and broken down into detailed tasks.
- The best practice is for the Product Owner to have a detailed plan for the next few Sprints.
- The task of a Product Owner is to maximize the value of the Agile team
Requirements are not communicated
- A big up-front requirement specification helps nobody.
- Use Cases must be communicated between the Product Owner and the development team before the development work starts.
- The development should never be based only on a document. This will always cause the first version of the software to come out as unsatisfactory. It is much faster to clarify the details over a telco, than to code-test-integrate for weeks and to find out that the requirement spec wasn’t top notch.
- Coding a non-communicated requirement creates useless technical debt.
- The best practice is to have a clear and shared plan for the next few Sprints
- Prioritization forces the team to have important discussions regarding the content and their importance. What user group to serve first? Non-functional or functional first? New features or regulations? The common symptom of “no estimates” is that the Sprints produces nothing functional.
- It’s the team that estimates the stories being planned for the next sprint, and it’s the team that commits to do their best meeting the sprint goals.
- When the Use Cases have estimates, it is easier to prioritize and plan their development. It is also easier to identify the cases, which need to be divided into more fine-grained Use Cases. Estimates are created semi-automatically when the requirements are communicated to the team. When the Product Owner clarifies the Use Case and the team divides it into technical tasks, estimates will emerge. Estimates will also inform the team velocity. If you divide all stories to roughly similar sizes then you can skip estimation and just count the number of stories.
- The best practice is to have a clear and shared plan for the next few Sprints
- No prioritization usually leads to starting too many Use Cases. This leads to Sprints that produces nothing.
- Incorrect prioritisation also delays feedback on critical decisions, while the team develops something irrelevant.
- The best practice is to have the product backlog prioritized for the next couple of Sprints. It should be fairly easy for the Product Owner, Scrum Master or the Architect to explain the Use Cases of the next few Sprints.
- The best practice is to start nothing new before something finishes AND then start the highest priority task.
- Less is faster
- Each Sprint should provide the team with feedback. The customer gets the demo. The team gets the retrospect. Each Sprint is a step towards better practices. One aspect is the project management tools with their analyses and reports.
- The best practice is to produce a functional demo and have a Sprint Retrospect. Repeat, the best practice is to have a retrospect after every Sprint.
- Reflect regularly
- The best way forward is to support or coach the inefficient team member. Usually, people are not lazy but too busy. Mentoring and coaching are good ways forward.
- The best practice is for everyone to keep developing and improving.
- Each team member must allocate time for self-development
- The team must be able to self-organize. Team members must be able to work individually, but more importantly they must be able to work as a team. Shared ways and common rules. Cherry picking when choosing tasks, coding too low or high quality, forgetting the common rules etc. are signs of a hot-shot not able for teamwork.
- The team must allocate time for team development
Doing the right things at the right time
Agility means making the right decisions at the right moment. Traditional management models are more interested in doing things right. This leads to an inside-out way of thinking. “We have a CMMi5 level quality standards”. And still, the customer gets no additional value. Such management creates tons of additional bureaucracy without creating anything useful. Agile development advances with the best possible speed towards the best possible direction. Speed and direction are revised constantly when new information and feedback emerges. In sports, one improves agility by doing neuromuscular exercises in a well-rested condition. The same goes for knowledge work. Stress, fatigue and haste kill agility; Work becomes stiff and laborious. W. E. Deming stated that 95% of performance issues are caused by the system itself and only 5% is caused by the people. Even talented people will fail if the system does not give them room and freedom to prosper. Organize outside-in. Customer first.
Exploring ScrumBut—An empirical study of Scrum anti-patterns
A fixed project always fails
Why to scale Agile
How to scale Agile
Reflect the ways of working in your organization
When it comes to developing the actual product, software developers have been adopting practices and tools that speed up the development cycle and simultaneously increase the overall quality of the service you’re running. These practices include things like test automation, collaboration, pair working, short feedback cycles, peer reviewing, modularisation, adoption of functional programming practices and continuous integration/deployment. You should integrate these practices into the development of infrastructure automation too.
As always, it depends on the context which tools and methods one should use, but I’ll make some suggestions as to how you might be able to improve your infrastructure development. The suggestions might sound too obvious, but for some reason, infrastructure development has been treated as a second-class citizen and a lot of the obvious improvements have been neglected. The purpose of improving your infrastructure automation development process is, in the end, to reduce inefficiencies and improve the reliability and speed of deployment.
Explicitly Reserve Time and Resources for Infrastructure Development
Developing infrastructure automation takes time and resources, but it is often treated as a side activity that doesn’t need allocation of resources. In our experience the workload of infrastructure/ops work and its automation takes roughly 1/5th – 1/10th of the resources compared to the development of the actual product or service in a typical server-driven environment. This is of course highly context dependent and the above shouldn’t be used as a strict guideline. But going way beyond this range might indicate misallocation of resources. And, at the very least, you shouldn’t feel guilty if you’re spending that much time for infrastructure/ops automation. It does take time.
The question of how to divide the effort to create and maintain infrastructure is a bit complicated. It is true that the DevOps culture tries to close the gap between traditional Dev and Ops roles, but it is rare that the Dev team takes the full responsibility for the infrastructure automation. Also, it seems that there is a tendency inside Dev teams for specific people to specialise to these tasks. I believe that the old strict separation of Dev and Ops activities is clearly inferior, but the type of collaboration model that works in each individual situation depends highly on the circumstances.
Make Your Infrastructure Development Cycle More Like a Product Development Cycle
When you accept that the development of infrastructure automation is similar (at least in some aspects) to any other software development activity, you need to start thinking how to incorporate the practices that have made software development faster, more reliable and more agile to your infrastructure automation development process. No longer should you be making one-line changes whose impact you only see in the production environment when the deployment of your software fails and your production suffers.
The picture below shows the typical arrangement of development activities and too often infrastructure automation is not part of the normal development cycle but is done ad-hoc:
Also, Continuously Integrate Infrastructure Changes
You probably are already building your software and running test suites for it after each commit. You should do this to your infrastructure automation code too. Preferably in a modular, isolated way. If possible, build tests for your infrastructure automation code too. Like in regular software development, these tests in a unit testing level should be fast and easy-to-run.
You could argue that if your continuous integration already runs your infrastructure automation when building your actual software then you don’t need to independently check infrastructure automation code. This is true to the extent that you don’t want to make duplicate tests for your code. Optimally exactly one test should fail if you introduce a bug. However, this sort of separation is really difficult to achieve. Furthermore, you should be able to test the infrastructure automation code in a shorter feedback cycle than as a part of some long-running operation that doesn’t clearly indicate the fault.
Run Your Infrastructure Code against Clean Environments
Special attention should be spent to decide how your infrastructure code is tested on clean, pristine environments. One of the big reasons to automate the infrastructure building in the first place was to provide a deterministic and documented way to recreate the whole environment from scratch. But if you don’t regularly do this you will get into a situation where this is no longer possible. Often the changes might work when added incrementally, but not when the whole environment is built from scratch.
The tool support for making virtual environments has taken giant leaps during the last decade, but it is far from a solved problem in my opinion. The speed at which you can set up the whole process and eventually individual virtual environments is still typically too slow. It should be a matter of minutes to set it up and matter of seconds to fire up new environments and run your code on it to make the development cycle comfortable.
The use of containers (Docker and alike) has helped this significantly, but it usually only involves the individual app or component. For any non-trivial software system, you’re going to have at least few containers and the surrounding glue and supporting services like monitoring.
Don’t Forget Documentation
One of the goals of infrastructure automation is to provide documentation of your infrastructure: as program code. This is vastly better than outdated manual documents or worse still some passed-on knowledge that’s only in few people’s heads. But as we know from “self-documenting code” in regular software development this is mostly just a fantasy. Even in the best circumstances, the code only documents the ‘how’ but leaves the ‘why’ unanswered. And the circumstances are not always the best.
This is why I recommend developing practices that encourage documentation of your infrastructure and also the actual automation code too. You will need high-level pictures, design documents, comments and well-designed and well-named infrastructure code. Perhaps one day all of your current team will be replaced by someone else and those quick hacks and strange decisions will make no sense whatsoever.
Think in Modules and Make Things Testable
I feel that there’s a tendency to neglect the practice of modularisation when making infrastructure code. What I mean is that in regular software development we’re careful not to introduce dependencies between functionally separate parts of the code, but with infrastructure automation, we sometimes slip these sorts of unnecessary interlinks between modules. What this often manifests as is a complicated or long procedure to enable testing of a simple component. For an example, it might be that running a single component in your setup first requires setting up multiple other components. Ideally, you should be able to functionally test the infrastructure code for your component without any extra dependencies.
This is of course highly dependent on the architecture of your actual infrastructure and sometimes you cannot avoid these dependencies. But I still think it is an important point to consider when developing the infrastructure and its automation. I find it helps to think in terms of test-driven development even if the actual testing as a unit is unfeasible. If you realise that in order to test a single component you would need to run all your infrastructure code first, you might consider a different approach for your code.
Peer Review for Improved Understanding and Efficiency
Peer reviewing is an easy and obvious way to improve your infrastructure development. It is too often the case that infrastructure development is left outside peer reviewing and other collaboration methods which further separates it from other development activities and often leaves it to only one or few people’s responsibilities. I’m not saying that each and every developer should contribute equally to all infrastructure development, but with peer reviewing you can spread knowledge and improve the quality of your code without too much effort.
If the reaction to a pull request of a developer who is inexperienced in ops/infra is that he/she cannot understand the change, then you should consider this as a great opportunity to teach the inner workings of your infra and secondly improve the change in a way that it makes it easier to understand. For example, adding comments or documentation of why the change was necessary or just improving the naming of things and so on.
The main lesson is that you should stop considering infrastructure automation as a side activity compared to the regular software development and start doing things that speed up the development and make the end product less error-prone. Improving the development process of infrastructure automation is not just yak-shaving: its purpose is to save you and your customer money. Finding bugs earlier in your development cycle is always a good idea and this applies to infrastructure automation too.
The annual X-Road Community Event took place in Tallinn on 12th September 2018. During previous years the event has been organized by Estonia’s RIA but this year the responsibility was taken over by the Nordic Institute for Interoperability Solutions NIIS. NIIS is an association founded jointly by Finland and Estonia in June 2017. Its mission is to develop e-governance solutions, kicking off with the X-Road technology.
Gofore acts as the NIIS’s ‘right hand’ as the development team working on the X-Road core. Currently, we are four developers working closely with NIIS’s CTO Petteri Kivimäki. The whole team was kindly invited to participate in the event and some of us were also given the opportunity to speak in the conference special tracks. So we travelled to Tallinn the previous evening and had some time to have a late dinner in the Old Town which was a very nice way to start the trip.
After an early night at the hotel, the next day the conference started with NIIS’s CEO Ville Sirviö opening the event. There were more than 150 participants from over 10 countries including Japan, the United States and Madagascar.
The event got an electrifying start when the host invited on stage representatives from the member countries Estonia and Finland and surprisingly Iceland too! Iceland joined the interoperability alliance as a partner and signed the partnership agreement on stage. This greatly strengthens the X-Road partnership and co-operative effort.
Next, the enthusiastic host invited Petteri Kivimäki on stage to present X-Road development model big picture and roadmap. NIIS maintains and develops X-Road core and provides support to its members. The advisory group evaluates business enhancement requests and approves new items to the product roadmap. The working group prioritizes product backlog, looks into pull requests and approves new enhancement requests to the backlog. X-Road Product Roadmap and Product Backlog are owned and managed by the NIIS. The current roadmap has Ubuntu 18 and REST support as the highest ranked items. It was also announced that the design of the next generation X-Road 7 will start during 2019.
There was a panel discussion about cross-border services between Estonia’s Siim Sikkut (Government CIO, Ministry of Economic Affairs and Communications) and Finland’s Anna-Maija Karjalainen (Director General, Public Sector ICT, Ministry of Finance).
Jarkko Moilanen (Senior Advisor, Ministry of Education and Culture, Finland) talked about API economy and best practices in API design.
Kristo Vaher (Ministry of Economic Affairs and Communications, Estonia) talked about Fact Driven Architecture. His vision for government services architecture includes a blockchain and the actual services are built on top of that.
Andres Kütt (Interforum OÜ) talked about X-Road design patterns. He introduced a set of recommendations and principles for integrating with X-Road.
There was another panel discussion about X-Road’s international use cases between Estonia’s Kaija Valdmaa (Project Manager of Estfeed, Elering AS), Iceland’s Einar Birkir Eirnarsson (Head of Division, Ministry of Finance and Economic Affairs) and Japan’s Masakazu Ohtsuka (Planetway). Valdmaa’s electricity company Elering is utilizing X-Road in reading meter data across national borders. Ohtsuka’s Planetway is evaluating X-Road technology in Japan’s private sector and hopes to expand its usage to Japan’s public sector in the future. Eirnarsson said they have evaluated multiple data exchange platforms including building their own solution but eventually they ended up with X-Road and the implementation project is currently ongoing.
After lunch, there was a Kahoot quiz about X-Road. People were distributed among specialized tracks based on their interests. The tracks were X-Road users, X-Road operators, X-Road developers and e-governance. Our team’s presentations were in users and developers tracks. Jarkko Hyöty (Gofore) presented the X-Road’s load balancing solution in the X-Road users track.
I participated in the X-Road developer track and gave a presentation about X-Road’s development practices.
The specialized tracks included a workshop encouraging the community to participate and create new ideas. The workshop I participated in was about future visions of X-Road. We were divided into groups where we figured out improvement suggestions and new features for X-Road. Finally, the ideas refined in groups were presented to everybody and collected together as suggestions for future work.
The conference day ended sky high on the 30th floor of the Swissotel overlooking Tallinn. Sparkling wine, people getting to know each other and nice discussions took place.
It seems that there is high demand for an integration platform like X-Road all over the world. It may be because different e-government initiatives require a common integration model to ensure cost effectiveness and ease-of-use of governmental functions. It also helps that X-Road is an open source solution and as such suits the needs of many nations.
Gofore has many years experience developing the X-Road core and related national e-government services. We are more than willing to help in any X-Road evaluation or implementation project.
Overall it was a very nice and well-organized event by NIIS. The X-Road community is already strong and getting stronger each year. Last year there were 70 participants and this year the amount doubled. It is now also a truly international event with participants and speakers coming from all around the world. I can’t wait to see how far we have come next year.
It has been 6 months since I joined Gofore and I can easily say I enjoy working here a lot. I am really thankful and happy to be part of my company.
I decided to move to Finland from India with my family after considering the facts like Finland having one of the best education systems in the world, and great work-life balance.
And all of this started when Gofore, an IT company in Finland decided to give me an opportunity even though my technical skills don’t align with their needs at the moment. Gofore recognized my interest and ability to learn new things.
With the courage to face the unknown, I travelled to Finland on March 8th 2018 and Finland greeted me with great white snow all around which was the first experience of snow for me. Even though I have travelled to the US and Japan before, I have never seen snow like this, which was overwhelming for me and I enjoyed it a lot.
The next day, I decided to visit the office just to figure my route since I didn’t want to get lost on my joining day which was a couple of days later. Without much hassle, I was able to find my office and then half mindedly decided to go inside and say Hi.
To my surprise, I saw many smiling faces which were eager to welcome me to the company and asked me to join them in a cooking event which they were going to have within a couple of minutes. I gladly joined them with no idea of what was going to happen.
It was the best night of my life, where I cooked with my future colleagues and had great conversations with many of them. And then it was like a normal thing to have many ‘best nights’ and days with great colleagues with whom I enjoyed working and having fun at after work parties.
Gofore amazed me in many ways, the great culture, awesome skilled people, happy smiling faces, the helping mentality of my colleagues, events, parties, yoga, football, company breakfast, summer party, foosball, Finnish lessons by colleagues, wine tasting, people persons, and a whole lot more benefits you could have as an employee and you are treated as an equal no matter which part of the world you are from.
And never before I had an experience where I was asked whether I would like to have a salary appraisal discussion even before completing 6 months. Its one of the two values of Gofore. Gofore is the best workplace for the employee.
I have had a really great experience druing my time at Gofore so far and I decided to create a small video about the company and how the work-life culture is here since I want to share this really good culture and wellbeing with everyone. This brings happiness to me and many others.
I came to Gofore with an experience of 6 years of IT and from 3 different multinational companies. But I would gladly tell to anyone I meet, that my career journey and my life started here at Gofore.
The React API is simple, but, from time to time you should return to the official React docs that are updated with new features and with validated ways of using them. Like this nice example of Async Refs: https://reactjs.org/docs/refs-and-the-dom.html#callback-refs
But if you have really hit the stage where your code becomes more of a legacy and not ready to be updated to a newer React version, my suggestion for you is to head to Frontend Masters. It has modern but easily approachable video courses, all available by a monthly subscription. You really should check them out: https://frontendmasters.com/
UI with components
Create components in a declarative manner so that the person using it doesn’t need to think about how it does everything it implements. With the React API itself, you can declaratively compose the UI. Just aim for a developer-friendly component interface that allows developers to compose your components easily. Remember that good abstractions make it easy to add code and behaviour, but really good abstractions make it easy to remove code and behaviour.
Going through object keys and values
Although Array.map is one of the most used ones – and for valid reasons – I still prefer the more powerful Array.reduce. (And map is just one implementation of reduce).
Example: Go through an object (key-value pairs) and check condition for each key to either return a new modified value or the original value.
Array functions can also be used for just to clear your code:
Public class fields
Babel will transpile your code and add a constructor for you behind the scenes. As described here https://hackernoon.com/the-constructor-is-dead-long-live-the-constructor-c10871bea599
So instead of this:
State changes with higher order functions
Note: State updates may be asynchronous by batching multiple setState() calls into a single update for performance: https://reactjs.org/docs/state-and-lifecycle.html#state-updates-may-be-asynchronous
If you know how to use higher order functions, here’s a really neat example to get you going also with React:
If this is is something totally new for you I can recommend these video tutorials by Fun Fun Function. Here are a few to get you started:
Higher-order functions: https://www.youtube.com/watch?v=BMUiFMZr7vk
ComponentWillReceiveProps has been deprecated and you should update their usage to componentDidUpdate. It will stop working at React 17. Read more about this and other (componentWillMount, componentWillUpdate) now legacy lifecycle methods from official React docs: https://reactjs.org/docs/react-component.html#legacy-lifecycle-methods
Example for refactoring:
Inspect the DOM right before render updates it (React 16.3)
Read the current DOM state right before the changes from VDOM are to be reflected in the DOM. It can be done using getSnapshotBeforeUpdate lifecycle method.
Example: Before the component gets a new render, detect if the user hasn’t scrolled the scrollbar all the way to the bottom.
Fragment or array (React 16.2)
Keep semantics clear. Don’t add unnecessary elements that just increase complexity (and complicate your CSS). Instead of adding extra wrappers (like <div>’s) now you can also return a Fragment or an array.
ErrorBoundary (React 16.0)
Create ErrorBoundary component and log your errors. Introduced at the React official docs: https://reactjs.org/docs/error-boundaries.html
Compound components, render prop, higher order components
A modern React developer should also learn how to make compound components, render prop, higher order components and other fancy patterns. Here’s a really good post briefly explaining them: https://blog.kentcdodds.com/mixing-component-patterns-4328f1e26bb5
Example: Figure out how much the document is scrolled vertically and pass it to a CSS custom property.
Experimental bonus: optional chaining (with Babel 7)
Babel 7 has a new plugin called babel-plugin-transform-optional-chaining that is based on ECMAScript TC39 proposal. Now instead of checking for null or undefined of every nested object separately, you can just chain them like this:
We all know how important it is to take breaks during the workday. It makes us more productive and increases our focus and what-not…
So why is it then, that even though we know it is better to take short breaks every now and then (preferably every 30 mins or so), we still prefer working for long periods of time and only take the break when our brain finally stops co-operating or our neck hurt so much it’s impossible to sit on the bench any more?
There are probably lots of personal reasons behind this, but let me try to tackle at least some of the most common ones.
You feel too busy to take breaks
This is probably the most common reason for not taking breaks frequently enough. You have a task at hand that you are supposed to get done before noon, and you realise you’re going to have to hurry to accomplish it in time. So taking a break would feel like slacking or a waste of time.
I also admit dismissing my breaks because of this. It is so easy to reason with yourself and skip the break. But let me assure you, even though you feel that way, the opposite is true. Even taking a short 5-minute break enhances your brain activity and gives a boost to your blood circulation, which makes you way more productive for the time you’re working after the break.
Besides that, your brain actually doesn’t stop working while you’re taking the break. Even if you don’t consciously think about your problem at hand, your unconscious mind is working on it full time.
You probably have experienced those moments, when you absolutely have to take a break (eg. to go to the toilet) and while taking the break, you finally figure out the solution for the problem you’ve been trying to solve for the past 2 hours.
You don’t want to lose focus and concentration
What could be more frustrating than being interrupted while working on a focus-demanding task? Especially when the task requires you to hold a lot of small pieces of information together in your head.
Interruptions coming from outside in this kind of situations are bad indeed. After being interrupted this way it might take you up to 30 minutes to get back on track.
You might fear the same holds true for taking voluntary breaks. But you shouldn’t. Actually, there is a distinctive difference between involuntary interruption and a voluntary break.
The biggest difference is the timing. As the research suggests, the brain can keep focused attention only in intervals from 20 to 45 minutes, after which the concentration starts to drastically diminish. So you want to take a break only after the attention span threshold, not during it as would be the case with outside interruptions.
Another distinction is continuity. When voluntarily taking a break, you have time to make a mental (or even written) note on where you’re at. This way it’s easy for you to come back to the thought and continue from there later. When you get interrupted, you probably can’t do that.
But now, the scientific studies have shown that taking breaks from a task can dramatically improve one’s ability to focus on the said task in the long run. In one study led by professor Dr. Alejandro Lleras from the University of Illinois, it was found that short diversions from the task at hand vastly improves focus. Here’s what Dr. Lleras said about the results:
“From a practical standpoint, our research suggests that, when faced with long tasks (such as studying before a final exam or doing your taxes), it is best to impose brief breaks on yourself. Brief mental breaks will actually help you stay focused on your task!”
You’re in a good flow and don’t want to break it (pun intended)
Everyone knows how good it feels to be “in the flow”. Time flies and you are so immersed in your work that you can’t even hear or see what else is happening around you.
It might be really hard to snap out of the flow to take a break, as you don’t even notice the time passing. Probably you don’t even want to since being in the flow feels so good.
But even though flow feels good, it doesn’t counteract the fact that your productivity diminishes over time. Despite being in the flow, your brain still needs a break every now and then to remain focused on the task at hand.
You feel guilty for not sitting constantly at your desk
In many cultures, taking a break is seen as being lazy and avoiding work. Even though you know it would be better to take a break, you still might have this nagging feeling of guilt when you do.
This one might be tricky to fight back by simply reasoning the benefits of taking breaks since it’s about how you think people see you as a person. If this is the case, probably it might be best to broach the subject with colleagues and see what they think.
If you can collectively agree taking breaks is for the best, then at least you would know your colleagues are not thinking you are lazy or avoiding work when taking breaks.
What can you do about it?
Now that you probably have gained a bit of motivation to start taking more breaks during your day, you might want some ideas on how to do it.
Here’s a couple of office hacks for you to increase the number of breaks you are taking at work. Try them out and see if one of them works for you. But don’t take this too seriously. In the end, the outcome should be that you enjoy your work more and have some fun in the process.
Office hack #1
Make it a habit to drink a lot of water during the day, and you’ll have a natural forcing factor to go and take a break every now and then.
How to achieve it? Here’s one way…
- Drink at least 2 or 3 full glasses of water (on top of the coffee you might drink) in the morning before leaving for work.
- If you did the first step correctly, you should feel the urge to take a break within the first hour at work.
- Whenever you visit the toilet during the day, make it a habit to drink one glass of water on your way back to your workstation.
Office hack #2
Make distractions your best friend.
You know the moment when you feel tempted to check your email, Facebook or look at your phone to see if you’ve got a message or two? That’s the moment when your brain starts to loosen up and it becomes hard to concentrate. As I mentioned earlier, it is perfectly normal for this to happen after being focused for a 20 to 45 minute period.
When that happens, let that be an indicator for you to take a break from the work you’re doing and see what happens. I bet you’ll be way more focused on your task after a short break.
So, whenever you get distracted, it’s probably the best time to take a break.
As a bonus reminder, if none of the previous hacks works for you, there’s always the good old and proven Pomodoro technique.
There are lots of good resources available on the internet about the Pomodoro Technique, so I’m not going to explain it in detail here, but the idea, in a nutshell, is that you work in 25-minute uninterrupted cycles and keep 5-minute breaks in between. After 4 cycles you’ll keep a longer break (20 to 30 minutes).
So that’s it for now. I hope you can incorporate something from this advice into your daily routines.
Here at Gofore taking breaks, having a good time and playing with your workmates during the day is a big part of the company culture. Everyone is encouraged to take breaks every now and then.