Our Way of Working The tech, tools, and teamwork behind WirelessCar’s innovative connected car services July 23rd, 2024 What is it like to work as a developer at WirelessCar? How do we stay at the top of our game in an ever-changing digital landscape? In this article, I will discuss some of the tech, tools, and teamwork that shape our work at WirelessCar. This in terms of both the innovative connected car services we develop and operate for our customers, and what it means to have a work climate that encourages creativity, curiosity, and community engagement. How freedom with responsibility characterizes our work at WirelessCar I started out at WirelessCar as part of a trainee program called Rising Stars, right after I earned my degree at the university. One of the earliest impressions I got from my new workplace was the great degree of freedom that characterized our work. Take the small but critical example of deciding which operating system to work with. Being able to choose the OS you are most comfortable with makes your job easier and more enjoyable. It demonstrates that the employer will provide me with the tools I prefer, so that I can be as productive as possible. More importantly though, the freedom at WirelessCar extends throughout the entire work process. There is a genuine openness to new solutions, where creativity and curiosity are actively encouraged. If someone wants to test a new or revised design pattern or service in AWS, or perhaps make a proof of concept, that initiative will most likely be welcomed. This largely goes for our programming languages, frameworks, and libraries, as well. While we mostly work with Java, many functions are written in Python or other languages; when they are preferable and may require less code, for example. Among our teams, there is a strong willingness to learn, and to try new ways of developing our products and solutions. How does WirelessCar’s way of working improve our customers’ business offerings? One idea tends to generate more ideas, regardless of whether the original idea can be realized or not. When developing connected car services (new and existing), we tend to leave no stone unturned. Pros and cons are discussed, rigorous tests conducted – both within each team, and among them. Our eagerness to try new things and see them from different perspectives means we can develop our digital services better and faster. When we do, we help lead the technological development and get a competitive edge. And by extension, so do our customers. The automotive landscape keeps changing rapidly, not least from a digital perspective, and is more competitive than ever before. We need to stay creative and curious – both as companies and as an industry – so that the OEMs can use that creativity and curiosity to their advantage in the market. The tech and tools of the WirelessCar trade What tech and tools do we work with, in order to develop, maintain, and improve our connected car services? Here is a brief summary of the digital cornerstones of this work. ● By utilizing and testing the cloud provider’s functions and services, we gain new knowledge and keep improving. Services can be built, tested, and adjusted smoothly and securely. Certain microservices and patterns can be shared among different teams, meaning that we do not have to reinvent or reimplement them. We mostly work with Amazon Web Services, but in some instances Microsoft Azure as well. ● In AWS for example, we regularly use AWS Lambda to run our code, SQS and SNS to pass messages to different parts of the services, and DynamoDB as one of our preferred ways of storing data. ● Java is our most common programming language, though other languages (including Python, Golang, JavaScript) are used as well, depending on what service or application we are working on. ● Many WirelessCar DevOps teams use the testing tool Cucumber to run their scheduled integration tests. We run some services in containers, and for those we may use Docker and the Spring Boot framework, for example. As for libraries, Project Lombok is a popular choice, as it keeps repetitive boilerplate code to a minimum. The same principle usually applies to both frameworks and libraries: if one is preferable over the other, and you also want to learn more about what it can do, then we tend to go with that. ● We use Infrastructure as Code (IaC) to keep ClickOps to a minimum, and a CI/CD pipeline to facilitate our work. This helps us develop new and existing connected car services with greater efficiency. Staying at the technological forefront is central to who we are as a company, and it has been ever since we got started, 25 years ago. ● WirelessCar’s connected car services are cloud-based and serverless. That means that they can be developed and deployed more easily, and be scaled up quickly, to keep up with our customers’ requirements. Our DevOps teams ensure the quality of our digital services – from concept through operation At WirelessCar, the teams that develop our services also operate them. These self-managed DevOps teams build, test, deploy, and operate our connected car services. Crucially, they also support our customers, the OEMs, throughout the lifecycles of these services. When a new connected car service is developed, each of our DevOps teams takes responsibility for the entire lifecycle of the project – from the basic architecture to the service’s continued operability. That means that as a developer at WirelessCar, you will get to build and own serverless structures from the ground up. That way, you will get to know your services through and through, which benefits everyone involved: the customer, our business partners, and your colleagues. You will be able to quickly make improvements, add new features, and answer questions and provide efficient support when needed. At the heart of it all are the collaborative efforts of all our DevOps teams. There are always new discoveries to discuss and learn from: what are the pros and cons of doing things a certain way? What have we learned from a certain work process? Can we make a service more intuitive, and/or easier to maintain? There is a shared sense of ownership of the connected car services we develop, along with a desire to constantly improve and innovate. On a personal note, this way of working has given me a great sense of pride in my job. Whenever I see a car model I have worked on, it is so rewarding to know that “yup, I was a part of coding the backend for that one”. If you have any questions about what it is like to work as a developer or software engineer at WirelessCar, you can contact me via the address below. For more on what we do, our DevOps teams, and our company history, check out some of the other articles on the WirelessCar Insights Blog. Here, we cover virtually every aspect of our work: AI and sustainable mobility, machine learning, cybersecurity threat intelligence, digital key solutions, call center services, PI planning, and a lot more. Isabella Fransson Software Engineer Contact
