Header Image by macrovector on Freepik We love to share our knowledge and improve each other That is why we have this series of presentations in the office about office ergonomics. Yes series, this is just the beginning, a general introduction to the topic. So this is a summary of the initial presentation. Later we will have more specific examples. Who are you to tell me what to do I am not telling you what to do but recommend ways to keep your joints and bones and muscles healthy, based on a lot of research and my own experience.

In the Devies book club we recently finished Modern Software Engineering by David Farley. In Modern Software Engineering, Farley want to reclaim the meaning of engineering in “software engineering”. It’s not just about coding, it’s about doing what works to build better software faster - This involves processes, tools and culture. The software industry is not like the manufacturing. The process of building software can’t be reduced to a production line; it’s rather a process of exploration and discovery.

Sometimes I see people (myself included) working on software development tasks in a non-structured way. You might have a vague understanding of what you’re about to accomplish. Aimlessly traversing the code base, hoping to find places that you might need to change. You instantly start to chase new ideas, while forgetting about prior (and possibly important) ideas. It might be hard to determine when you’re done. You might not commit intermediary working states, and have a hard time finding what you’ve messed up once something is broken.

Background This is probably not news to anyone that has been working as developer consultant. Large existing code base; in our case it’s an application that has existed for about 2,5 years and during that time it has developed several services and therefore has many endpoints. Therefore when me and my colleagues had to start developing new features it was hard to know what was available and what wasn’t with over 50 different endpoints to hit.

tl;dr Background Continuous Deployment (CD) pipelines are great tools to automate the deployment process of a software. Their main objective is to minimise human error and maintain a consistent process for how the software is released. For Xcode projects this becomes a time critical process once the project has to be built for different configurations and/or environments. Since every configuration might require a different signing method, or even different deployment platform.

At Devies we run a book club where we on a weekly basis discuss topics from a book that we are reading in a common pace. Recently we finished The Pragmatic Programmer, 20th Anniversary Edition. In this post, we’ll share learnings around some of the topics we have discussed. Tracer Bullets vs Prototypes Two of the topics discussed in the book are tracer bullets and prototypes. The concepts are similar but addresses different problems.

Hey fellow developers! Upgrading libraries in your gradle file for an Android project is a crucial part of keeping your project up to date and running smoothly. However, it’s not uncommon to encounter errors or deprecated code after upgrading a library. If this happens to you, don’t panic! There are a few steps you can take to fix the issues and get your project back on track. Understanding the Role of Gradle Files In an Android project, there are two main gradle build files that you might need to work with: the “build.

Last week I ended up spending more time than I expected on debugging. I spent most of the time figuring out why a library did not accept my freshly generated RSA private key. I was supposed to provide the RSA private key as an environment variable RSA_PRIVATE_KEY. I wanted to store the RSA private key in a file private-key.pem so my first attempt became RSA_PRIVATE_KEY=\"$(cat private-key.pem)\" docker-compose up -d, which failed due to decoding issues by the library.

A common dilemma within the field of software development is traversing too deep within documentation to discover the solution to a bug. This struggle can be represented and reflected in many aspects of life, however as developers we encounter this dilemma more often than not. This post is about how I fell into this dilemma and got bamboozled by Apple’s integrated development environment, Xcode. It’s ten o’clock in the morning and I’ve just configured and bumped the dependencies for my client’s android application which they hadn’t touched for over two years.

Every software developer should keep a diary. Personally I’ve kept one for about a year now, and I’m very content. During some periods I haven’t bothered, and that’s OK. I can always write a new entry tomorrow, or next week. The diary can cover a lot of different aspects from your daily work. Below are some examples. Things you’ve learned Accomplishments that you’re proud of Thoughts on dynamics within your team Sketches of ideas Reasoning behind technical decisions Solutions to problems that you’ve struggled with I think the greatest benefit of writing a diary is that you give yourself time to reflect on your daily work.