Vaadin not only develops frameworks for building applications. We also develop actual applications. In all of these, we use our tools to some extent, but many deliveries by our Services department are fundamentally generic Java software projects, or consulting on them. This is probably the place to find the best experts in actual usage of Vaadin, with a vast amount of experience on general Java software development.
I had a chance to interview one of our most experienced consultants on the subject of developer productivity and the skills and tips he often gives to new team members or our customers. Petter has years of experience with code, projects and software architecture, and has mentored a number of junior team members to become top-class developers.
Understand how your frameworks work
Frameworks and the abstractions they bring in are good, but when using them, you should understand the full picture to get the most out of them. When using tools like Hibernate or Vaadin, you can often forget you are working with relational databases or web technologies, but it certainly helps if you understand how they work. All abstractions are leaky to some extent, and with all non-trivial libraries and frameworks, you will eventually have some kind of an issue. At that point, you will be much more likely to find the solution in a reasonable time if you actually understand how your tools work.
Petter urges you to learn at least the basics of the tools that are used in the project and to try to understand the reasons why they were adopted for it. Frameworks are opinionated by design, which means they will more or less forcibly guide you in a certain direction, regardless of whether this direction is actually good for your particular project. He has seen a lot of unnecessary code that could have been avoided if the basic features of, or the motivations behind, the libraries being used had been known by the developers. And, understanding why they are used helps you to feel motivated to contribute better code for that project, even if the library isn’t your personal favorite.
Swing vs Vaadin code comparison
Box dataInputBox = Box.createHorizontalBox();
dataInputBox.add(new JLabel("Type value:"));
final JTextField inputField = new JTextField();
dataInputBox.add(inputField);
JButton button = new JButton("Submit");
button.addActionListener(new ActionListener() {
@Override
public void actionPerformed(ActionEvent e) {
facade.save(inputField.getText());
}
});
add(dataInputBox);HorizontalLayout dataInputBox = new HorizontalLayout();
dataInputBox.add(new Label("Type value:"));
final TextField inputField = new TextField();
dataInputBox.add(inputField);
Button button = new Button("Submit");
button.addClickListener(new ComponentEventListener<clickevent>() {
@Override
public void onComponentEvent(ClickEvent event) {
facade.save(inputField.getValue());
}
});
add(dataInputBox);Figure 2: Vaadin code example
Vaadin and Swing code looks almost the same, which certainly helps to reuse existing skills. But without figuring out how Vaadin actually works, you can’t get the best from it. And you might even accidentally create nasty security issues.
Petter gave as an example Swing developers turning into web developers using Vaadin. One can get a lot done with Vaadin with only Swing and Java knowledge, but to really unleash the power of the framework, one needs to understand how it works behind the scenes. In some cases, it is not only about productivity, but also about security. Some new Swing developers starting on Vaadin do not realize that web applications are always multi-user environments, unlike their old Swing project.
Books, tutorials and documentation are the main ways to learn new tooling, but Petter places one less-used method on the table: reading the code. Java IDEs are superb tools to navigate through code, especially if you’re using open source products for which the IDE can automatically download their source. The documentation of open source products is not always top notch but, even if it was, sometimes reading quality code is simply faster for an experienced developer than reading the docs. Don’t have a mental barrier between the library code and your code; navigate boldly to the other side, he says.
If all you have is a hammer, everything looks like a nail
This well-known quote by psychologist Abraham Maslow also applies well to software development – for libraries, architectural patterns and even methodologies. Petter said it ought to be obligatory for each and every library developer to write overdose warnings into their documentation. ORM and DI are good examples of tools that are truly valuable for many problems, but are often adopted without proper reasoning. Or, if all you need is a static web page, it doesn’t make sense to add Vaadin or React to the equation.
The same applies to architectural patterns and methodologies. For example, the MVP pattern and Scrum are proven to excel in a huge number of projects, but can be total productivity killers for others. Petter remembers a project where they had a large number of small things to fix and implement. Moving away from scrum-by-the-book to a simple Kanban-board-based approach helped their team to spend significantly more time on things that actually made a difference.
Petter rephrases his message by saying it is ok and natural that everybody has their favorite tools, but applying them to every single project just doesn’t make sense. Software development is most often teamwork and we just can’t always get our favorite tools for the projects. Have a reasonable amount of tools you master in your kit and use the right one for the project.
Testing is to make you more productive
When I ventured to ask about productivity tips for testing, I think I got my best lesson of the day. By the way I put my question, I revealed the wrong attitude that too many developers have. As Petter put it, the purpose of testing should be to make ourselves more productive – not to prove our code is flawless.
Of course, there are ways to be more productive in testing, as well, but too many developers consider testing to be just something it’s necessary to fulfill to deliver the final artifact. Tests should be there to help us bake the artifact to a shape where it can be released, both for the first time and iteratively during its whole lifespan. Understanding that properly helps us to create the right amount and right kind of tests (e.g., a good combination of integration and unit).
In testing, Petter urges using even more teamwork than in actual coding. The developer is rarely a domain expert in the field, so the actual users are really valuable here. The product owner and, if possible, real users of the software should already be involved in testing in the early phases of development.
Another concrete tip was about the test data. Try to use as realistic test data as possible, from the beginning of the project. No amount of testing can save your project if it turns out the day before the release that your data structures or algorithms can’t handle the data that the actual users have. A trivial example of this is the maximum lengths of text columns in a database. If possible, derive the test data from real sources, but be sure to anonymise it before saving it to your software project, to avoid nasty data leaks.
If you still have to generate the test data yourself, don’t try to be funny with it. Your boss should be able to take a screenshot of the development version and show it to potential customers without embarrassing the company. It is better to use John Smith as a test user than Adolf Hitler, for instance.
Use the flow - carefully
We’re talking now not about the full-stack Java web framework, but the mental state that many developers try to make a permanent state. Petter himself loves this feeling when all the pieces seem to drop into place almost magically, time flies, and you'd love to get the whole problem tackled in one go. Many developers recognize this state of mind, but it also burns a lot of mental energy, and you might eventually suffer burnout. Software engineering is an endurance sport, not a sprint. Cutting your flow early helps you get to the same productivity level easier and more repeatedly in the future.
And vice versa. Software engineering is a creative job that sometimes refuses to proceed, even if you’ve tried really hard. Have a break or do something else. Try going for a run or walk. Petter has noticed that the most complex problems often get solved when hopping on a bike to ride home from the office.
Discuss and learn
The best way to become a great developer is to spend a lot of time with code, trying out new things (while resisting the urge to put every shiny, new tool to use in the next customer project, just because you want to try it for real). Hobby projects are an excellent way of improving your skills.
The second-best way to learn about software development is to discuss it, for example on a coffee break or in code reviews. Having to explain your reasoning to another developer is an effective way of gaining more insight. If you don’t have the luxury of having Petter Holmström as your teammate, discuss it in StackOverflow, Twitter or Discord, or join live events like meetups or conferences. If you have a gut feeling that your current way of working isn’t the best, ask how others are doing it.
And I’m asking, what is your best tip for becoming a more productive programmer? Comment below!