Performance. Errors. Logs. One Tool. Everything Developers Need to Support Their Apps

Stackify Blog

Subscribe to Stackify Blog: eMailAlertsEmail Alerts
Get Stackify Blog via: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn

Blog Feed Post

Brian Madsen, of the LIDNUG Talks Team, Time Off and Tools

Brian Madsen is a full stack developer residing in Stockholm, Sweden and the founder of the .NET User Group on LinkedIn (LIDNUG) that boasts upwards of 52,000 members. In his career, he’s worked in architecture and moved to team lead and then development lead in the last 5-6 years. He’s currently a consultant with byBrick.

Brian has been building in .Net since 2001. We were lucky enough to talk with him for our Aug/Sept issue of the BuildBetter eMag, and there was more great insight than we were able to cram into the publication, so we wanted to share it here. We asked Brian to give us a general view of developing in his part of the world, give us some insights about building great development teams, hear how he deals with work/life balance and (of course) we wanted to talk tools. As an early tester of Prefix he gave us some feedback about the free tool. Here’s our interview with Brian Madsen in its full glory.

From a development culture standpoint what do you find unique in your area of the world?

Brian: First off, Stockholm is a tech hub. There is a huge amount of startups coming out of Stockholm.  There is a huge focus on technology and technology delivery. Technology itself, due to the nature of a lot of the startups, has to be very agile. I know that is a bit of a buzzword. They need to be able to swap out technologies and platforms as they grow. Up here, the way they build applications, the focus is more about finding the right tool for the job. That being said large organizations that run both in-house and outsource projects, tend to focus very heavily on their general procedures, whether that be program management or portfolio management. It’s a lot of focus on that.

What do you think the development team of the future should look like?

Brian: You need different experience levels, that’s not to keep cost down, ultimately you have to think a bit further forward than just the next 6 months or next year. I think the idea of having graduates or interns moving to new positions it’s something rarely done. The ideal development team is a good mix of seniority throughout the team.

One of the things that is important is communications, so the people involved with the team not only learn from what is going on they are able to contribute more. Sometimes the most senior person or any other person may not be the right person for the task, due to experience. Development is an exposure world. The more you get exposed to the more you get to know. If you sit in a black box by yourself, you tend to learn only what is in your immediate vicinity.

Secondly, it’s important for developers to work hand and hand with testers. Developers, we sit generally on machines and everything works fine, but suddenly you throw a couple thousand uses, things can go terrible really fast.

Lastly, security, it’s one thing that doesn’t seem to be talked about very well. At least defensive programming techniques, understanding the risk of doing things, cutting corners, or implementing things may have potential security risk around it. Very few times do I see development teams having any sort of security focus, much less security specialists, either doing penetration testing or anything around applications in their environments. And very few tools are available that contain tools that assist you with finding security issues. In my previous job we were very lucky to have part of the business that was focused on information security. It becomes a different type of development when you suddenly throw security into the mix as well.

As a developer, what was the one thing within your profession that you would say you hated most about your career or your job and the one thing you loved most?

Brian: I think one of the things I have hated but also loved most has been, as a developer you have been expected very often just do what needs to be done, even if this means a 16-20-hour work day, or working through your weekend. I think early on, when I was younger that seemed to be the norm.  I have to admit after the first 10 years of my career, (I have been doing this 17 years now) I don’t think I have never worked a 40 hour workweek. That’s been the bad, both family, health everything. I think working hard for something as a developer has been rewarding in its own right but also has its negatives – lack of family time and lack of time to learn.

So, as you look back now and as you lead teams, are you an advocate for the 40 hour work week or are you an advocate for the, “let’s just work really hard and do whatever it takes and reap the rewards of that.”

Brian: I think there is a very fine variance that you have to do. If you are working on applications or systems that have a certain level of business criticality, if something goes terribly wrong on a Friday afternoon. It’s very hard to say, “oh it’s 4 o’clock, it’s time to go home now.” If the scenario is there, I am always willing to get things done, but I don’t think is should be an everyday occurrence. You get burnt out, you starve attention, errors, and you end up redoing and spending more effort to get outcomes due to having worked 12-14 hours. On a day-to-day basis you should keep to a set workday. You need rest as well. A tired developer is more likely to make bigger mistakes or miss details, than a well-rested developer. Plus, motivation holds an impact. We are all human, there has to be a fine balance between work and life, definitely.

You’ve been using Prefix for a while. We’re dying to get your thoughts about how it’s going.

Brian: I am currently using it not just personally but I am currently using it on a project I am on.  I have introduced it to several of our developers. The development environments around this project are very complex. It takes three days to put your machine together and get everything installed and configured. I must admit, one of the things that impressed me first was how easy it was to get Prefix up and running.  I expected a lot more clicking and configuration to happen then it did. I am using it and it is helping me very greatly. In this particular project, they didn’t have any architectural diagrams of what the applications were doing. As you read through thousands of lines of code to try to form a picture of where this calls to, what it is doing, you can really spend a lot of time spinning your wheels. One of the things I really like about Prefix was it just stacked it up. I could see every single web call that came from the application, and that was a really good help as a tool for that to start with.

How often do you find you use Prefix?

Brian: It’s pretty much 24/7! I am luckily enough our client has provided me with three monitors. The third monitor, Prefix just sits there. I find it very handy. Even just in general terms, I make changes to code run up a verification again. If something goes wrong, I can see it, I don’t’ have to debug through anything. Debugging takes a while. In here, if there’s issues that get called or exceptions that get thrown, even if they get caught and dealt with so often, I can see them right away. And I can compare it to the last time I ran it.  To see, “oh, this is what it is doing now.” Did it improve or did it get worse?


Connect with Brian

_ _ _ _ _


If you’d like to know what else is in Brian Madsen’s developer toolbox, grab your copy of BuildBetter eMagazine v1.2

BB-CTA-Bannerhttp://1piygz303e2p3ze2nt2kfhla.wpengine.netdna-cdn.com/wp-content/uploa... 300w" sizes="(max-width: 650px) 100vw, 650px" />

Read the original blog entry...

More Stories By Stackify Blog

Stackify offers the only developers-friendly solution that fully integrates error and log management with application performance monitoring and management. Allowing you to easily isolate issues, identify what needs to be fixed quicker and focus your efforts – Support less, Code more. Stackify provides software developers, operations and support managers with an innovative cloud based solution that gives them DevOps insight and allows them to monitor, detect and resolve application issues before they affect the business to ensure a better end user experience. Start your free trial now stackify.com