At the core, the job of a software developer is and has always been the same: writing good, elegant, sustainable and bug-free software that exceeds the expectations of your clients. But the context in which we do our job is changing and with it the skills required to be a great software developer. In this talk, I want to go through a couple of things that I think make the difference between a developer and a great developer. This includes some technical skills and practices, but also non-technical things that you might not consider relevant for a developer at first.

1. How to become a great developer
Corsin Decurtins, Netcetera
JavaDay
2014-11-22 / Skopje

2. How many people here are…
… developers?
… not developers?
… application developers?
… great developers?

3. How to become a great developer
Corsin Decurtins, Netcetera
JavaDay
2014-11-22 / Skopje

4. Notes
About this talk
I do not consider myself a great developer.
I have always wanted to become a better developer.
I have learned a few things along the way that made me a
better developer.
I have seen qualities in other people that I consider make
them great developers.
This is what this talk is about.

5. Notes
About this talk
Observations and interpretations of qualities of other people.
Half-baked theories and predictions about the future.
Retrospective observations about myself and things that
made me a better developer.
Skills that I think are important for developers, and will be
even more important in the future.

6. Basics

7. Notes
Basics
I will not talk much about the basics.
Of course you need to improve your development skills.
Learn about things like
Clean Code, Good Design, Test-Driven Development
Agile Methodologies, Test Coverage, Complexity
Design Patterns, Reactive Programming, …
But you already know that.

8. Code

9. Notes
Reading Code
Code is something we deal with every day
Focus is usually on writing code. But reading code is a great way of
learning things.
Coding style, design patterns, naming conventions, formatting,
algorithms, data structures, logging, …
Create a habit of reading code
Code reviews
Other projects from your company, libraries, code on Github
Look at the code of open-source components that you use

10. Architecture

12. Notes
Software Architecture
Developers sometimes have negative connotations with architecture
Software architects are the guys in shirts and ties that tell you what to do,
but do not really know what they are talking about
Software Architecture is a property of a system
It’s about the big picture; it’s about things that are difficult to change
Software Architecture is way to important to leave it to the “Software
Architects”
Be interested in Software Architecture and learn things about it
Simon Brown’s Software Architecture for Developers is my recommendation

14. Notes
Learning New Languages
You have probably already heard this one.
Learn new languages, even if you will never really use them.
Languages always come with a way of thinking, a way of
looking at the world.
First-class citizens and concepts of programming languages.

15. Notes
Learning New Languages
You learn a new language.
You are confronted with a new way of looking at the world and
at computing / programming.
You can use ideas and concepts from one language in another
language.
You learn about core concepts and different ways of looking at
the world
You learn to learn new languages

17. Notes
Software Development
Writing Code
Avoiding Bugs
Well-structured, clean code
Automated tests
Robust design, flexible, scalable, adaptable, extensible
Delivering value to the customer

18. Notes
The great software developer
A great software developer is great at writing code
Learn about good architecture, clean code, automated
testing, continuous integration, design patterns and
principles, …
But software development is about a lot more than just writing
code, particularly when we are talking about application
code rather than frameworks, libraries and components.

19. Software
Development
Testing
Quality Assurance
User Experience
Interaction
Graphics
Marketing
Operations
Architecture
Management
Business
Security
Product Management
Legal
Requirements
Engineering

20. Notes
There are lots of other parties involved in a Software
Development project.
The actual software development is just one part of the
overall process.
People who are experts in other domains contribute to the
software development project.
So how do you collaborate with all these parties … from a
software developers point of view.

21. Group N-1
Group N
Group N+1

22. Group N-1
Group N
Group N+1

23. Group N-1
Group N
Group N+1
Group N+2
Group N+3
Group N+4

24. Notes
Collaboration used to be from one group to another, usually
through some formal artefacts like documents, code or
similar deliverables.
Feedback was not very prominent in this old model of
collaboration.
Essentially, this is waterfall thinking.

25. Software
Development
Testing
Quality Assurance
User Experience
Interaction
Graphics
Marketing
Operations
Architecture
Analytics
Management
Business
Security
Product Management
Legal
Requirements
Engineering
DevOps
Analytics
DDD Scrum
Test
Automation
Scrum A/B Testing

26. Notes
Collaboration between the different groups is changing.
Lots of buzzwords are around nowadays (as seen on the previous
slide). What a lot of them have in common is that they include a
much closer collaboration between different groups of people.
Devops is a good example for this. At the core is promotes a very
close collaboration between software developers and operations
people.
More interaction, more feedback, more informal communication
and collaboration.
This is basically the idea mentioned in the Agile Manifesto.

27. Agile Manifesto
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

28. Software
Development
Testing
Quality Assurance
User Experience
Interaction
Graphics
Marketing
Operations
Architecture
Management
Business
Security
Product Management
Legal
Requirements
Engineering

29. Notes
Agile Collaboration
Fewer formal interfaces between the different teams.
Focus on collaboration and communication.
Much more feedback.
Redefinition of the “team” as a group of people with a common
goal (and completely different skills) rather than just a group of
people with the same skills and tasks.
This has an impact on us as software developers and on the
skills that we need.

30. Software
Development

31. Notes
Making your skills available
It’s not just about having good technical skills and knowledge
It’s also about making those skills available to your clients
The value of a developer lies within what he or she knows
and can do, but also how well the team and the client can
make use of this knowledge and skills
Think of it as the functionality that you provide and the API
through which you expose this functionality

32. Software
Development
Testing
Quality Assurance
User Experience
Interaction
Graphics
Marketing
Operations
Architecture
Management
Business
Security
Product Management
Legal
Requirements
Engineering

33. Notes
Collaboration with other Experts
Various groups of non-experts are often involved software projects
These are actually not non-experts, but just experts in other
domains than yours
Having some basic knowledge about these other domains help in
the communication and collaboration
You do not need to be an expert, but it helps to know some
things, particularly what drives the people, how they think, what
they care about and what they value.

34. Business Domain Knowledge

35. Notes
Business Domain Knowledge
Knowledge about the business domain is particularly important.
At the end, this is the area where you as a developer are trying to provide value. Do not
be scared about the business domain.
Understanding the customer/client. This means multiple things:
-Actually understanding what the client or customer is talking about. Terms, words,
expressions, …
-Understanding what the client/customer is interested in and cares about.
-Understanding how what you are doing creates value for the customer.
Formalizing the (often informal) concepts of the customer. In the end you have to explain
this to the most stupid (but extremely reliable) worker of a company: the computer.

37. Notes
Domain-Driven Design
DDD is a framework that builds on this idea
It is about a lot of things, but in particular, it also contains the
idea that:
All the people involved in the software project should use the
same concepts (although at different levels of abstract) and
speak the same language (at very different levels of detail and
with very different focusses)

38. Business Domain Knowledge

39. Learning as an Attitude

40. Notes
Learning as an Attitude
To some people, this might be obvious; to some it’s not
I have often encountered resistance to learning about the
business, i.e. developers who do not want to know about the
business details and almost actively reject to learn anything
I do not think that you get very far with this
A great developer in my opinion should embrace this or at least
accept that he or she might learn something about the
business by mistake

41. Management

42. Notes
Management
The management is another red flag for many developers.
You do not have to become a manager, if you do not want
to.
But to know how managers work and what they care about,
is extremely useful for a software developer.

43. Languages

45. Notes
English
English is the de-facto standard language in IT (and business)
Everybody needs basic English skills
Advanced English skills make your live much easier
Communication and conversation in English should be effort-less
Accents are perfectly fine
Investing in improving your English helps you to become a more
valuable developer
Make use of opportunities to read, write, listen to and speak English

46. Presentation Skills

47. Notes
Presentation Skills
Presentation skills are very useful for developers.
Presenting at conferences with Powerpoint etc. are only one
form of this.
The essence is the ability to summarise complex concepts,
explain them to people with different knowledge backgrounds.
A talk at a conference is one form of this; asking a lead
developer about making a refactoring can be another form.

48. Open Source

49. Notes
Open Source Projects
Contributing to open source projects are another great way
to learn a lot of things.
You collaborate people who work differently than the
colleagues in your day job.
You can learn a lot about technical topics, but also about
collaboration and communication.

50. Conferences, Talks, …

51. Notes
Conferences, Talks, …
I can only encourage developers to attend conferences,
talks, user groups, meet-ups, …
You can learn a lot at these events and you meet a lot of
interesting people.
Make use of opportunities, attend events and maybe even
contribute actively to such events.

52. Software
Development

53. Notes
Summary
A great developer needs excellent technical skills.
But that is not enough.
It’s also about making those skills available to other people
The value of a developer lies within what he or she knows and
can do, but also how well the team and the client can make
use of this knowledge and skills
This “API layer” is already very important today and I believe that
it will be even more important in the future

54. Corsin Decurtins, Netcetera
Chief Technology Officer
corsin.decurtins@netcetera.com
@corsin

55. How to become a great developer
Corsin Decurtins, Netcetera
JavaDay
2014-11-22 / Skopje