I have been presenting on a variety of topics lately. If you would like me to speak at your event please contact me on twitter @sarahtarap
You have just been promoted to a Tech Lead role - Congratulations! But something is wrong :(. Suddenly, you’re struggling and under delivering. Everything you thought you knew about being a great developer is thrown out the window.
Being a Tech Lead is more than just being the best technologist in the room. In fact, the objective of a Tech Lead is completely different to a Senior Engineer. A Tech Lead’s sole aim is to make the delivery team as effective as they can.
In this talk, you will hear how Sarah has helped many upcoming Senior Engineers transition into successful Tech Leads. You will learn more about the expectations of the role and take a look at key attributes for a Tech Lead. We will dive into the five key capabilities that they need: Custodian of Vision, Project Management, Information Radiator, Mentorship and Productionising the Tech; which are underpinned by Influence Skills, Leadership Styles and Conflict Resolution. If you have been struggling with your new responsibilities, or you are progressing towards this role, this talk is for you.
It’s easy to find a complex solution to a complicated problem. But it takes another level of expertise to craft a simple solution. There is a direct relationship between the complexity of a system and its cost of ownership. Complex systems are difficult to understand – they take time for new team members to learn. Diagnosing critical issues in complex systemsat 3am, when you’re half asleep, takes many cups of coffee. However, when we focus on discovering a simple solution, all that changes for the better.
Simple solutions require different approaches than the ones we usually use to create complex systems.
In this session, Sarah Taraporewalla will describe these approaches, which include Domain Driven Design (DDD) and its adoption of Ubiquitous Language; an understanding of how cognitive biases interfere with complexity, and modelling tools which help simplify and aide in communication. By sharing some examples of complex systems she has seen, you will learn the reasons behind the complexity, and what approach she used to help simplify them.
Our industry undeniably suffers from a lack of gender balance amongst hands-on technologists. Even fewer of those technologists are mothers. Sadly, many women believe that you can’t remain technical once you become a mother. But there are small changes that we as leaders can make to support our team members as they transition back into the workforce.
In this talk, Sarah will share with you her experience, including the challenges she faced, of returning to a senior technical role after starting a family. You will hear the changes she made within her company to make it easier for others to see how to return and stay technical, and the benefits to her company of having her and others like her able to return to work.
Sarah hopes her experience will provide some inspiration and practical advice to share with your software engineers and tech leads who are contemplating motherhood, and for leaders who are committed to supporting diversity in their workplace.
All it takes is time to write complex software, but it takes skill to deliver simple solutions. Why is it so hard to write simple code? How does complexity creep into our system? And what can we do to guard against complexity?
In this talk, we will explore the code structures that help drive towards simplicity, (and those to steer clear of) and how language and the metaphors we use directly affect the simplicity of our solution.
By focusing on these two areas, your code will be easier to read, easier to maintain and easier to explain to other team mates (and future you). Simple.
When the Agile Manifesto was written, it was decided that there were only four simple statements at the heart of Agile. So, it is with great sadness that, when we scrutinise most teams, we discover the first, and arguably most important, of these statements is disregarded. Teams focus on Processes and Tools, rather than Individuals and Interactions.
This session aims to redress this balance, by focusing on what it means to value the individuals on the project and their interactions. We will take a dive into the human psyche, to see what happens behind the mask, take a trip into what it means to be a team, instead of just a group of individuals before finally exploring what it means to be a leader in an Agile team.
How often do you get to work on isolated systems? More often than not your system needs to integrate with other another system, whether it be a legacy system, an external API or even one that has not yet been developed. Every integration point adds risk to your project: technical risk, quality risk and delivery risk. But never fear - help is at hand! Come to this talk and you will hear: - How to design your system to decrease risk, - How to ensure the quality of the overall system is high, and - How to manage the delivery of the system in a way that guarantees success You will hear real-life cases - some success and many failures. You too can learn from the mistakes I witnessed.
Pairing isn’t really a technique, it’s a skill and as such some people are better than others but everyone can practice being a better pair. Pairing is not universally better than solo programming, it tends to be more time consuming but produces better quality code and spreads understanding of the codebase around a team. No more getting stuck if the “Message Bus Guy” isn’t in the office.
Pairing 101 aims to introduce what kind of activities are good for pairing and which aren’t. It will also try to explain how you can develop your skills and also explain how to be an absolutely atrocious pair. In his book Outliers, Gladwell shares the story of a Korean airliner crash caused by issues in the cockpit. That example brings to mind the excitement and challenges of what would seem to be the simplest of XP practices: pair programming. Simple on the surface (2 people, 1 computer); challenging in reality, we will dig into the tricks and benefits of effectively pair programming. Join us for a fun, interactive session as we identify concerns teams face when starting to pair, explore the many benefits of pairing, and give you our best tips and techniques to make your pairing more effective!
We know that testing is important; that separation of concerns is important; that modeling our domain is important; and that their are often many domains within an application. So why is it that most of the view engines make it so easy to break all these important activities?
View engines, such as erubis and ERB, make it so easy to break the model-view-controller-paradigm by allowing turing-complete code in the view. It is so easy to pull the database into the template by making calls such as <%= Order.find(:all, :conditions => { :status => 1 }) %>. Oh no! Now separation of concerns is thrown out the window, closely followed by testability and domain modeling.
Never fear - there is a better way! By following the teachings of String Template, we can introduce a strict enforcement of the model-view-controller-paradigm. In this session, we will highlight the problems with the existing engines, explore the possibilities of String Template and introduce Slippers - the ruby port of string template.