QCon New York – Tutorial Days

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!