Christian Peters

Posts

Are you running a SOLID Meeting?

Teams can spend a lot of time in meetings. Most meetings are held with good intentions and can lead to the desired outcome. However, I think most people would agree that they spend more time in meetings than they would like. I believe that the main reason for this is that too often a meeting is scheduled without having a clear plan or goal for the meeting. The thinking seems to be that there is a problem that needs to be addressed so if we gather everyone together we can figure it out. Teams work to plan and organize their work before actually starting the work, so why would we think that putting together a meeting without preparing for it would lead to positive outcomes? I think that a little work before a meeting is scheduled could go a long way to make meetings more engaging and leave the attendees feeling like it was worth their time. Introducing the SOLID meeting Developers use a mnemonic, SOLID , for describing how to structure good code. Using these same letters with d

Design Pattern: Unit of Work

The Unit of Work pattern defines an approach to create logical transactions within a system that might otherwise not be transaction based. It commonly is used in conjunction with the Repository Design Pattern. I have previously used the Unit of Work pattern only in relation to database operations, but it could be used for file access, other sources, or multiple types together; the key is that all work gets completed as if it were one action. Reasons you would want to use the Unit or Work pattern Allows for smaller components that do not need coordination logic More efficient by reducing duplicated or unneeded work, only the final result is stored Ensures working with up-to-date entities If one piece fails, all fail, guaranteeing data in a good state How do you implement Unit of Work? In my opinion, one of the best ways to use the Unit of Work pattern would be for your Unit of Work to be created as soon as a request comes into your system and to be completed right before yo

Design Patterns Series

Design Patterns are an approach to solve problems when creating a piece of software. They are useful as a best practice template when solving a problem. They also give you and your teammates a common understanding when discussing how to solve a given problem. That common understanding only happens if everyone on your team knows the patterns. I am using this space to collect a series of posts that will dig into my understanding of common Design Patterns. Repository Pattern Unit of Work

Design Pattern: Repository

The Repository Pattern is a pattern that defines how to access data in a reusable, isolated fashion. The core concept is to isolate the logic required to call a database, file, or other data source. It can be reused without other layers of the software needing to know the details of how to get that data. An example would be the connection string for a database should be used in 1 location, within a repository, rather than every class that needed data needing a connection string. The repository is used by calling classes like a collection of data. If I have an employee repository, classes that need an employee can query the employee repository as if all employees were already in an in-memory collection. var employee = _employeeRepository.FindById(1); I view the repository as the bottom layer of code. Isolating data access from the rest of your code has multiple benefits. You can easily write tests by faking or mocking your repository. You do not actually connect to your data s

Intern Project, a look back.

This summer I was able to be the Lead Developer for our intern team. The team consisted of a developer that was chosen as our Leader, he was able to show his leadership ability in a setting that he would not have otherwise had access to. Myself and another full-time developer helped to mentor the interns and build out the site. And, of course, four interns that are studying software majors at their universities. These four had very limited experience with developing a website before coming to work here and also did not really know what it means to work in an enterprise-level team environment. Over the course of 11 weeks, with roughly 50 working days we were able to design a new website and build it from nothing into a fully functioning site that will add value to our business. Everyone had amazing opportunities to learn and grow and come together as a team. The people that we were at the start of the summer are so much better with more knowledge and experience to draw upon now at the

Developer Job Description

What do you tell people when they as what you do for a living? Do you say that you are a programmer or developer? What if they follow that up by asking what that means, or what your daily activity means? I have an answer that I think describes what I do best. Problem Solver I am first a problem solver. I generally use technology as the tool to solve problems, but there are also times when a non-technical answer is really the best solution. Being able to break down the problem at hand and see it from different angles always me to provide numerous different solutions, then talking or thinking through those options should lead to the best possible solution. This works very well in a team environment because everyone has different ideas. Someone else will think up other ideas than I will, by sharing our ideas together we can build new ideas together. Code Author When a technical solution is chosen and I start writing code, I shift into a different role, Code Author. Here I am focu

Interns: Taking off the training wheels

My intern team has been working for several weeks now on our new website. We have already completed one deployment to production and are finalizing our second one. We started with a plan to release often adding small bits of functionality as we go and so far that plan has been working really well. We already feel like we have accomplished a lot because we have completed many of our project's requirements and should easily be able to complete the rest giving us time to do even more than just the original requirements. One of the things I have had some difficulty balancing has been how much to lead the interns and how much to let them figure out on their own. In deciding what our team process should be and how we should allocate our time, I think it was important for me to do more leading. I saw some deficiencies in how we were currently working and brought up some ideas for how we could address them. We had moved into spending all our time just working through stories and did not