QCon New York 2014 started out with two days of ‘tutorials’, lasting 3 to 6 hours instead of the 50-minute sessions during the rest of the conference.
On day one I sat in on the session about improving your ‘hiring process’. Most people who have been responsible for hiring staff for their company or projects, or have been applying for a job themselves, might probably recognize that most job-adds aren’t really appealing, or don’t attract the right persons.
Most current job-adds are really boring, stating a lot of what is required from you (the engineer) and not much of what they (the company offering a job) are offering.
Pete Soderling started out with stating that most software engineers are attracted to their jobs for two reasons:
- they like to solve difficult problems
- they love to work with smarter people
Now, knowing what engineers appreciate, it’s all about ‘telling the story’ about what unique opportunities exist at your company/project, and using the right ‘channels’ to share your story.
Of course, most people would think it’s a challenge to come up with a unique story, but during the exercise one of the participants asked our host how to do this “because they were only trying to come up with a solution to replace their existing legacy system with a new system, in the meantime keeping their site online which services a million users a month“. He almost ended up with a few people applying for a job right on the spot…
Furthermore Pete gave some tips on how to attract more applicants for your job-add, and how to streamline your internal hiring process.
On day 2, I joined in on the session about Domain Driven Design, by Eric Evans.
I’ll try to sum up his session with the following points:
- agree on the terminology (get an Ubiquitous language for your project)
- don’t overdo it, stop modelling after a few iterations
- the critical complexity of many software projects is in understanding the domain itself
- re-evaluate your model when new problems arise
- use ‘code-probes’ more often, to inexpensively evaluate some assumptions
- split your model into ‘aggregates’, groups of ‘classes’ which logically belong together, and can be changed disjunctive of other aggregates.
- accept not all data changes have to be applied over your entire model IMMEDIATELY. Engage the business into discussing what parts of your model need to be updated ‘real-time’, and what parts can be updated in a later stage.
- again, don’t shy away from creating a new model, when your current model, although perfect for its current use, is not up for the job.
- it’s important to understand the relation between the different aggregates in your model, and what strategies to use on these relations (working together, just re-using the other model, translating between models or several other strategies).
- try to focus your modelling effort on your core-business, which might be just 10% of all the software you develop
- use your best developers and modelers to improve your core domain
- and again, when your business changes and new problems or opportunities arise:
either re-evaluate where your core business is (and where to focus on)
re-evaluate the models to your current issues
re-evaluate the strategy on relationships between your aggregates.
More on QCon in the next update!