João Duarte
12 February 2016

João Duarte is a Portuguese embedded software engineer and a consultant of Alten Technology in the Netherlands. Currently he works at Lely, a Dutch agricultural machine manufacturer.

A little over two years ago, I went to a job fair in Lisbon, Portugal, looking for a new challenge. There, I met Alten and after a couple of interviews we decided to work together. So far, I feel very happy with the decision of moving to the Netherlands, both personally and professionally, and I only regret not making the move before.

One of the main differences I have experienced is the amount of companies active in embedded software. In Portugal it is really difficult to find a job in this area, while in the Netherlands there are lots of opportunities. Being at a consultancy firm like Alten gives me the opportunity to meet several companies, see how they work, see the techniques and tools they use. My impression so far is that the level of engineering in the Netherlands is quite high and everything seems to be very well organized. Another difference is the hierarchy. Here, all the companies I have been working at have a flat hierarchy, which is something I really like.

Alten Joao Duarte

Currently, I am assigned to work at Lely, a company that develops products for agriculture – not just harvesting machines but also a wide range of robots to be used in farming, for example for milking, feeding and cleaning animals. The variety of fields that come together in a robot, such as sensors, actuators and communications, is very appealing. Also, despite Lely being a big company with international representation and a considerable number of employees, I really feel a family atmosphere, not only between colleagues but also in approaching the managers.

My team at Lely is developing software that is going to be used by all the teams inside the company. Currently, we are working on a Canopen library.

Monday

We start with a meeting, to discuss which features we think should or could be implemented in the Canopen library we want to develop. We have spent last week reading the Canopen standards and drafts from CIA (Can in Automation), and we have created an overview of the devices that are currently being used at Lely and the ones intended to be used in a near future. As a result, we have an idea of the possible Canopen profiles the library will have to be able to deal with. We can now start discussing in a more detailed manner exactly what needs to be implemented and also which features are the most important and have to be addressed first.

Tuesday

After having studied the protocol and having explored within the team which features to implement, we need to discuss this with the Lely teams that are going to use the library on a daily basis, i.e. the teams that are using or are planning to use, in a near future, Canopen devices in their projects. We want to tell them what we are planning to implement and want to invite them to give feedback, to see if their needs are met.

Wednesday

My team gets together again, to start thinking about the design of the library. We have knowledge about Canopen and we know what the teams need the library to do. It is now time to see how we are going to implement it. First up is the interface the library will provide to the user.

Thursday

Thursday is presentation day in the engineering group: engineers at Lely share their technical expertise with their colleagues. Presentations can be about particular company projects or about projects developed privately at home. We are doing this Thursday’s presentation, to share our ideas for the future Canopen library with our colleagues. This way we can not only expose our ideas to the entire group, but also make sure that we get feedback from a large number of engineers and managers.

Friday

We now have a clear idea of what we need and we have some specific features for the new library in mind. The team reconvenes to decide on the details that will be part of the lower layers of the library and as such will not be visible to the user. We start work on the documentation that will reflect the design and will form the basis for implementation and testing. This will keep us busy for the next few weeks.

Edited by Nieke Roos