About Pascal Welsch
Hi, I’m Pascal Welsch, a self-employed Software Engineer with focus on Flutter applications.
After 6 years of professional Android development my passion shifted towards Flutter where I can build apps for multiple platforms. As Google Developer Expert for Flutter, I speak at conferences, build open-source projects and write blog posts about my learnings.
I love building stunning user interfaces and fluid animations. But I feel the same passion when I build SDKs, libraries, tools or business logic in a test-driven manner.
I used to work as Android team lead acting as a coach, not a manager. This role allowed me to give honest feedback and share knowledge in code reviews, pair-programming sessions and in regular coding dojos.
If you’re looking for a developer like me, contact me!
How I work
Tests are essential
Tests are a crucial aspect of software development and a quality factor. Not only do tests verify the correctness of components, they also prevent accidental behaviour changes when adding more features. A good test suite allows me to iterate faster. When all tests run after refactoring, I have nothing to worry.
TDD (Test-Driven-Development) is a great method to build business logic modules. It helps me to focus on the problem. This way I don’t write code which never runs. It keeps my solution simple, stupid.
Testing doesn’t necessarily mean TDD. In front-end development, having a test for every little fade animation doesn’t scale. Instead I use UI Tests to cover business related click paths through the app.
Knowlege sharing
To build successful innovatie software, it is necessary to have a collaborative team, pushing each other for better results. Most of knowledge exchange happens during Code Reviews, where author and reviewer learn from each other and agree on the best solution for the problem.
Another way to transfer skills in a team is via Pair Programming. Having two developers working on the same laptop, solving problems together prevents and creates a shared codebase where nobody “own” parts of the project.
Additionally, working so close together shares micro skills – like keyboard shortcuts and terminal commands – which otherwise might never be shared.
Automation
One goal as a software engineer is to automate everything. It prevents errors and humans doing boring repetitive tasks. Mobile projects should have at least
- automated tests for each Pull Request on a continuous integration server,
- automatic warnings from static analysis for common code smells and
- fully automated release processes to upload apps into stores.
But as the project grows, more automated tools might be required:
- Integration tests for REST APIs to detect if a 3rd party API removed required fields
- Automatic changelogs of merged Pull Requests from last sprint
- Automatic gerneration of third party licenses overview
Every project has different requirements and most require custom solutions. I love building those!
