I love working with legacy code! It's great fun to dive into a system that we didn't write and figure out how to improve it. Last year, I jumped at the opportunity to work with a startup on a Ruby on Rails code base where developers had left and business users needed support. As I dove into the code, there were a few surprises lying below the surface but my experience was not a miserable one. I enjoyed the challenge of an incredible learning experience. I'll be sharing my key insights from this project in my presentation at SCNA with code examples to illustrate. Come along to this talk to hear some practical strategies for getting to grips with an ageing code base while setting realistic expectations about what's possible.
Bryan Liles leads the ksonnet team at Heptio and is an avid tinkerer, philosopher, and mispeller of words. When not writing or thinking about software, Bryan spends his time using other people's software.
We rarely start from nothing. Life progresses and jobs change. One day, you will find yourself in a new job with new people you don't know working on software that is foreign to you. What do you do next? To some the answer is, "panic." To the seasoned the developer, this is yet another challenge in a career full of challenges. In this talk, I want to review the reality of trying to write software in the situation where the tech, the people, and even your own self-worth are in a dubious state. How can you orient yourself, what do you do first? How can you turn negative progress into positive progress? After you have a foothold, you will want to start improving the process of building software. What does success look like and how can you measure it? Finally, I'll end with the most important part of software development, the people by focusing on why relationships are important.
Eric Smith is an experienced software crafter and coach at 8th Light who has trained teams of all sizes to adopt software's best practices, and test various challenging portions of their system. He also leads code retreats that reinforces a developer's fundamental skills by stressing illuminating edge cases.
To develop his training curricula, Eric draws from his extensive experience as a software developer and consultant. In addition to his training duties, Eric continues to craft innovative software solutions for some of 8th Light's largest and most challenging clients. A consummate polyglot, Eric has deliberately worked on projects that force him to build complicated products and employ many different languages to reinforce his code sense.
Eric earned both his Bachelor of Science degree in Computer Science and his Master's of Science Degree in Video Game Development from DePaul University.
The first department of CS was established at Purdue in 1962, and the first programmer calling degrees a waste of time was born moments later. It’s fair to say that Universities have been battling the perception that what they teach is “too theoretical” and that they don’t produce working programmers for the majority of their existence. Meanwhile the rise of boot camps, online learning and of course apprenticeships has provided an alternative way to begin a career in programming.
Degrees are expensive, time consuming, and expensive (worth mentioning twice). So why do so many with non-traditional backgrounds report Imposter Syndrome? Why are freshmen textbooks, like SICP, so popular with experienced developers? And if Software Crafters are going to dismiss university education, then shouldn’t we stop comparing our job to professions like Doctor and Architects, and instead to a skilled trade like Electricians and Plumbers?
In my career I’ve mentored apprentices to become professionals, trained professional developers to become team leads, but also spent 9+ years as a student in higher education—so I have first-hand experience on both sides of this issue. In this talk we’ll propose a solution to the conundrum of the Degree vs. Alternatives, and maybe figure out how to make the current system work for you.
Mona has been leading multiple engineering teams at Dow Jones as Senior Director of Engineering for 2 years. In that time, she has built highly-productive and successful teams to deliver high quality software efficiently, and established delivery processes to achieve growth. She is a results-oriented leader and has worn various hats in her career in the past working at Amplify, Intent Media and Thoughtworks.
As an active leader in tech community, she has led the NYCSelenium meetup for around 3 years,speaks at various conferences sharing her experiences and learnings, and also helps people to adapt new technologies via her blog.
During my struggle to build strong and effective teams, I designed the Engineering Pillars framework. The framework has 4 themes: People, Delivery, Resources and Architecture. Strengthening each pillar and its main features has helped me to build effective and productive engineering teams. I have been using these pillars to explore the areas we need to improve upon for each team, identify and allocate the right people to own these areas, and build further on them.
With this talk I will be sharing my experience of building and strengthening engineering teams. The key takeaways for attendees would be:
• What are the various areas that needs to be focused on in an engineering team?
• How to identify people and skills to align with each area?
• How to structure teams to make them effective?
• How to align multiple teams to deliver on company goals?
Sam believes that empathy and openness should be a developer's sharpest tools. He also has a strong passion for learning and teaching. He loves outside-in coding and using tests to influence a system's design.
Sam is a Double Agent at Test Double, living in Philadelphia, PA. He organizes the Meetup Software as Craft. He is a cook and cyclist in his free time. He loves his family, craft beer, and good coffee.
Which conveniences do we take advantage of everyday? Which are taking advantage of us?
Objects and functions sure are convenient, so convenient that we do many shortsighted things just because they're easy.
In-line objects and anonymous functions create a poor signal to noise ratio, making it hard to understand your code.
Learn ways to give confusing things names, focus on what's important, and write nicer code.
Nikolai Avteniev started his professional career in software at JPMorgan Chase, where he participated in the Extreme Programming (XP) Pilot coached by Kent Beck. After earning a graduate degree in Computer Science from NYU, Nikolai took the experience of building and running an Agile development team to Real Time Risk Systems, where he was one of the two founding engineers. While there, Nikolai leveraged the Agile software engineering values and practices to build a successful software product that helped hedge funds manage multi‐billion‐dollar portfolios in near real‐time. From there, Nikolai joined New York City AdTech start‐up Intent Media, were he experienced Agile software development applied in a larger organization with multiple teams coordinating to deliver new product features at a furious pace. Nikolai currently works at LinkedIn in the NYC engineering office. You can learn more about his role from this recent blog post.
The contemporary code review practice has been adopted by many organizations and open source projects as a quality assurance measure. This process typically involves software tools such as Review Board and the time of one or more peer reviewers.
However, there is a growing body of empirical research about this broadly‐adopted practice that can help us learn more about the effects of code reviews on software quality. Available research shows that in fact, peer code reviews are better suited for knowledge sharing and code improvements, rather than for eliminating code defects or reducing error rates. The effectiveness of the process seems to depend on the experience of the reviewer with the code, the size of the change set, and the rate at which the review is conducted.
In this talk, I will share how the LinkedIn Flagship Product Engineering team leverages the code review process to spread organizational knowledge and uplevel individual contributors. I will also discuss the tools we’ve built to support this practice across a team which spans three offices, four development stacks, dozens of teams, and hundreds of individual contributors.
Joe Leo (@jleo3) is the founder and president of Def Method. After spending more than a decade delivering high-quality software solutions spanning government, education, finance and e-commerce, Joe set out to offer something unique in New York City: a development shop of talented engineers who can step back and see the bigger picture. Joe brings his mix of engineering muscle, business acumen, enthusiasm for challenges, and technical leadership to the helm of every Def Method project. He specializes in Test Driven Development, Pair Programming, Technical/ Team Leadership, XP and Lean Development Practices, and Ruby, Rails, and JRuby.
When working to manage a product team it is paramount to be able effectively know when things are going south. As the President of top software consultancy, Def Method, I have found that certain processes and methods can help you to project out to the future and see when things are not going as smoothly as anticipated in order to give yourself time to respond and work to get the project back on track. On a high level what I have learned is that:
• The problem is just past your computer screen.
• The more you talk, the more patterns emerge.
• Humans use similar language to describe the challenges in front of them.
• For every pattern there is an anti-pattern.
• Some language anti-patterns portend disaster.
• Act! Get on the same side as your team/company/customer and work the on the problem together.