- The Effective Engineer: How to Leverage Your Efforts In Software Engineering to Make a Disproportionate and Meaningful Impact by Edmond Lau
Detroit.Code() is another conference under the Amegala umbrella and I was pumped to be here. I spoke at Indy.Code() earlier this year and had a blast so I was already looking forward to going to another Amegala conference.
For the conference, we were going to be staying at the Detroit Marriott at the Renaissance Center in downtown Detroit. The hotel was very clean and quiet, my room was great, and I had a fantastic view of the Detroit River and Windsor, Ontario, Canada
For the venue, we’d be presenting at the Renaissance Center in Detroit. From an attendee perspective, this was great because going from my hotel room to the conference was as simple as an elevator ride. This was super convenient if I needed to go back to my room in case I forgot something or to get ready for the attendee party.
For the conference itself, the organizers tried two new ideas with what I think were mixed results. The first was to not have a speaker’s room. For those who aren’t aware, most conferences have a room just for the speakers where a speaker can make adjustments to their presentation, socialize with other speakers, and to relax. At first, I wasn’t sure how that was going to work out, but with the conference being so close to your room, it actually wasn’t that big of a deal. In addition, I found myself interacting more with the attendees since there wasn’t a dedicated room.
For the second idea, Amegala changed how they gathered feedback for the sessions. Instead of using index cards similar to Indy.Code() or what I’ve done in the past, they actually included a section for feedback in the website with the idea that you would login to the website, click on the session and leave feedback.
This is a cool idea because speakers can get immediate feedback without waiting on the organizers to gather the data, format, and send it out. However, some of the attendees weren’t aware they could leave feedback in this form and since they have to log in to the website, there was an added barrier to leave feedback.
I typically don’t attend workshops at conferences, but I’ve been learning more about Angular lately and I heard that Justin was a great presenter, so I was looking forward to this workshop.
This was a full day workshop that started you from nothing and you built up a To-Do application using Angular. But before you step away, this isn’t your average To-Do, this application handled data persistence using 3rd party APIs, a way to log in with a username/password, deploying, different ways of doing forms and more.
In addition, this workshop has some of the best documentation I’ve ever seen (take a look for yourself: http://digitaldrummerj.me/angular-tutorial/). Clear steps, example code, ability to copy snippets instead of hand-typing and what the completed code should look like at the end of every section.
I was only able to catch the first half of the workshop, but this was so well done. It took the pressure off from having to keep up with everyone and allowed me to go at my own pace and ask questions if I got stuck. Seriously, if you get the chance, go to this workshop.
Overall, I had six people attend the session and zero left feedback in the official channel. However, I was able to catch up with one of the attendees (Sam) and we were able to chat more about how to work with static classes with dependency injection.
In this session, Gabby presented on Logic Applications, what are they and how to create one. I knew absolutely nothing about this topic, but it turned out that Logic Applications are a Microsoft version of IFTTT (IF This Then That) hosted in Azure.
Logic applications work by defining two different pieces, actions (what to do) and triggers (when to start). For example, a trigger may be Whenever a SharePoint page is updated and the action may be Send an email to Cameron with what changed.
To show, she created a Logic app that would send an email to her if there a tweet was sent containing #GoGabby and the tweet was recognized to be positive by leveraging Azure Cognitive Services. It seemed very straightforward to create the application and to wire the pieces together.
Something interesting about Logic Apps is that there isn’t much programming, it’s more like selecting pieces having them fit together to perform the steps you want. As Gabby said, it’s closer to putting puzzle pieces together than writing code.
Overall, I thought Gabby did a good job with demonstrating what Logic apps can do and how to set them up.
Overall, the reviews were pretty positive with 5/20 responding with 4 “great”, 1 “ok”, and 0 “awful”. Attendees who left feedback mentioned the following:
Loved his style, you could tell he was comfortable and the information presented was highly informative.
It was really cool and great to me from OO background.
Great show of how functional programming can be helpful to making developers better at writing code. I learned that I should make classes smaller, more fail safe, always return an object of some sort, and how to use functional programming to drive my skill.
In this presentation, Curtis cleared some of the confusion around “what is DevOps”. For example, DevOps is not using the cloud. DevOps is also not a team or a position, DevOps is about communication and making sure that everyone is aware of what’s going on. DevOps is the opposite of “throwing it over the wall”. For example, if a developer choose a particular technology, it’s letting the infrastructure team know about the technology during development, not right before pushing it to production.
Throughout the presentation, Curtis refers to two books The Phoenix Project and The DevOps Handbook. I’ve read both of these books before and it was reassuring to hear that his take on the books was close to what I was thinking. In addition, he was able to clarify a few concepts that I can now leverage for the DevOps’ process at work now.
Overall, I thoroughly enjoyed his presentation style and content. For it being the last slot of the day, he brought some much-needed energy into the room to cap off Day 1.
In this presentation, Jeremy covers what are design patterns, where the inspiration of a pattern comes from, and how even though we aren’t conscious of them, we’re using some of these design patterns in our day-to-day work. The problem we run into is when we unconsciously use a design pattern because that means we didn’t consider the weaknesses of said pattern.
To demonstrate, Jeremy covers four different patterns (Observer, Proxy, Chain of Responsibility, and Iterator) and how through typical work, we seethese patterns. For example, when we register a handler for a button’s onclick event, that’s using the Observer pattern. When we wrap an external resource (like a SOAP service) and treat it like it’s a local resource, that’s using the Proxy pattern. When we add multiple catch blocks for exceptions, that’s an example of the Chain of Responsibility pattern. Finally, anytime we’ve used a foreach loop, that’s an example of the Iterator pattern.
I’ve seen some of Jeremy’s sessions before so I know he’s a great presenter, but what I particularly enjoyed about this session is that he removed some of the ivory tower mysteriousness of design patterns and made them very approachable for a developer.
In this presentation, Ryan covers some of the advantages of following a feature-first approach to software development. To start with, the idea of grouping files by concept (like models in one folder and views in another folder) might make sense for a small application, but as time goes on and the application grows, each of these folders will have dozens of files and it’s hard to find anything.
Instead, what if we had feature folders? The idea is that everything related to the feature (models, views, controllers, services) lives in the same place and therefore, it’s a bit easier to find what you’re looking for. In addition, this promotes the idea of vertical slicing of an application instead of the more traditional horizontal (layers) approach.
One advantage of using feature folders is that toggling features on/off (i.e. feature toggles) is really simple because you either include the feature folder or not. As someone who’s looking into taking on a more DevOps approach to software development, the ability to easily include/exclude features is nice!
Overall, Ryan’s presentation covered some great points about feature folders and how to migrate your current application to use feature folders
In this presentation, Richard covers on how to develop a solid application using Angular for the front-end and ASP.NET core for the backend while respecting major architecture concerns. In Richard’s opinion, an application needs to respect Scalability (the ability to grow horizontally), Extensibility (switch one layer out with another), Separation of Concerns (UI shouldn’t know about the business rules), Security, and Availability.
Most of the presentation was demonstrating a speaker registration application built with these concerns in mind so it was interesting to see how someone else approached solving a problem with the above constraints in mind.
Overall, I thought Richard did an excellent job outlining the architectural concerns of building an application and how to leverage Angular with ASP.NET Core. In addition, he was able to handle a lot of questions from the audience about certain design decisions and how they made sense given his concerns.
In this presentation, Curtis discusses the importance of having a mentor and how having a mentor can supercharge both your career and life and that by mentoring, you’re helping someone become a better person.
What I really enjoyed about his presentation is that he covers the kinds of mentors you’ll encounter and the strengths of one over another. For example, a career mentor is great for you learning on the job and getting better, but they’ll typically not do a great job in your life outside of work. On the other hand, a life mentor can really help make sure that your relationships outside of work are going well.
Overall, this was my favorite session of the conference. Not only was Curtis able to make a strong argument for the benefits of having/being a mentor, but he was able to entertain and connect well with the audience. If you get the chance to see Curtis give this presentation, go to it!
For the first ever Detroit.Code(), I thought the conference was well put together. There were hardly any issues with the space, the workshops and sessions were fantastic and the attendees were great. I appreciate the hard work the Amegala group put in to make this event as successful as it was. I’m already looking forward to see how Detroit.Code() will grow in the future.