About Punkcoder

I am a Software Developer with a passion for Security, ALM, Agile, and Coding Practices. I have been working in .NET as a developer for over a decade, a network admin for years before that. I have worked for large companies and small ones, many that you would recognize some that you probably interact with. I am opinionated and deeply curious about the world. If you have a problem there is a good chance that I would be interested in hearing about it. More than that I want to help others, mostly because I believe that helping a single person raises the quality for everyone.

Chall Profiles


Blog Posts

Everyone Can Code

Published On: Feb 24, 2017

There is an ongoing movement to try to make software development and coding available to everyone. I completely understand where people are coming from, giving someone the ability to feel the power if bending a computer to their will. I understand the desire to have everyone participate… But I don’t think that anyone has followed through with the real question…

Should everyone be a programmer?

I know that this entry is going to end up coming off elitist, usually this is the argument that comes out when you try to suggest that something is just going to be outside of someone elses skill set. But lets break this down in a way that we can make sense…

In 2012, 3,328 people were killed in distraction-related crashes. About 421,000 people were injured in crashes involving a distracted driver.

Programming is hard. Programming requires focus and attention to detail. It requires thoughtful planning, to do it right. The above statement is a point where people are doing something that they know could cause the death of themselves and others, in a task that they do every day, simply because they through that their hair, cellphone, or newspaper were more more important than the ton of metal that they were driving. Assuming that not everyone that drives distracted is going to die every time that they do it, it’s safe to assume that the number of people who do it is much higher than the statistics provided.

For years I have heard people who are super proud of the fact that they didn’t need a degree in computer science and are doing just fine working as developers, and sometimes thats the case. Occasionally you find someone who really just gets it, but more than likely these were people who were drawn to computers in a way that they don’t teach in school. But more often than not we see that there are people who were never really trained, still super proud of their work, who are fucking it up for those of us who really do know what we are talking about. One of the most important things that my college degree taught me wasn’t the ability to write code, I could do that before I walked in the door. It was the ability to look at a problem and understand the inherent problems that exist there in. The ability to spot a good idea from a bad one, and the ability to look at something that is hard but doable.

In the end it is important to find those people who do have the flare, because we do need people, smart people, to fill roles. This is already a problem and with the declining state of education in the United States, paired with the general repulsing of reality that seems to be going on right now. But for the love of god, just because you built a login page doesn’t make you a programmer, neither does moving a turtle around a screen.

Negative work

Published On: Dec 29, 2016

Every once in a while you get the opportunity to work with people who really make the process of writing software really nice. People who know the right patterns to build the right type of software, those are the projects that are almost over as quickly as they start, if you have never had the experience of working with one of these people you are really missing out… but this post isn’t about them.

This post is about the people whose contribution to a project can be felt in a negative way long after they are gone. These are the people who leave little treats all over the code base just waiting for someone to trip up on their code. The find the worst parts that you have been trying to phase out and make them the core components of their new work. They are the people who never submit code reviews, the people who never right unit tests, the developers who think that they should just write the bare minimum needed to get the code to execute then they call their work done, assuming that the person who is going to be dealing with their code when it goes to production will be long gone.

In the past I have worked on projects where the mentality is that everyone needs to be working, so when there is availability they move developers to projects to make them chargeable. The problem is that you never pick up good developers this way, why? The answer is simple, good developers are usually struggling to keep the broken project that they are working on together. Talented developers get into a habit of moving from one fire storm to another in the consulting world, because of their skill they usually demand a higher bill rate which means that when things are going well most businesses see them as the first thing to cut, since they are so expensive. At least thats how it works in the consulting world. But I digress…

The problem is that when you take a bad developer and add them to a system that either has a lot of problems (that are in the process of being fixed) or is in the early stages. Both of these are extremely dangerous in the fact that their impact unchecked can have disastrous consequences downstream… take this as an example found in the code of a peer.

    var loadIndices = function() {
        indexFactory.get(function (data) {
            var firstIdx = true;
            data = data || {};
            data.indexDetails = data.indexDetails || {};
            angular.forEach(data.indexDetails, function (data) {
                data.isOpen = firstIdx;
                data.isDisabled = false;
                indexFactory.getFields(function (returnData) {
                    data.fields = returnData.fields;
                }, data.indexName);
                firstIdx = false;

Example #1: Wait so where is data scoped ???

The reality is explained in the breakdown of time for another item that was included in the same project.

Time for developer to do work: 16 hours
Time for me to code review: 1 hours
Time for developer to update bad code: 3 hours
Time for me to track down bug that slipped past: 4 hours
Time for me to track down bug related to settings not being configurable: 4 hours
Time for me to change Dictionary<string,string> to message: 15 hours

Example #2: Actual time spent cleaning up a poor design choice ???

Best Of Defcon 24 Villages

Published On: Dec 3, 2016

So I am currently going through and reviewing all of the videos that have dropped from this years defcon, and since I am going through and watching them I thought that I would make an effort to currate the list. So with that I should say that there is nothing against your talk if you don’t appear on the list. It just means that you didn’t speak to me. The best part of DEFCON is that there is a free exchange of Ideas. With that said here is my list:

Biohacking Village

Carhacking Village

Crypto and Privacy Village

Hardware hacking Village

Packet Hacking Village

Follow Up From Prairie Code

Published On: Nov 4, 2016

So I’ve been back from Prairie.Code() for about a week now and I got the results from my talks. I am currently in the process of collecting my thoughts and trying to turn them into usable items for reflection.

Feedback on both of the talks was sparse but good, and I am very thankful for everyone that came out and learned something. I am hoping to give the same talk again via video confrence for any that are interested in hearing, and sharing. If you want to be kept up to date on that just leave a comment on the page and I will make sure that you get added to the list.

I am going to be looking into other confrences after the begining of the year, if you are hosting one or know of one that you would like me to speak for please don’t hesitate to leave a message below.

1o57 List of Things to Learn

Published On: Oct 12, 2016

I was going through some of videos from past defcons and I came across a listing of the things that every hacker should know as part of their education. The reality is that we all come from different backgrounds.

What is included below is a personal list and my progress through the list (I wanted some place that I would be albe to keep a list of things to work towards), your milage may very, void where prohibited:

Things to Know (at a basic level):

  • Binary Math - Need More for Higher Math
  • Hex - 5 / 5
  • Tor - 4 / 5
  • Shodan
  • IDA Pro (and Vivisect)
  • TCP/IP Fundamentals - 3 / 5, it’s been a long time since TSM
  • ASM
  • C/C++
  • Basic Crypto - 2 / 5
  • Wire Shark - 2 / 5
  • How Lame Nessus Is - 5 / 5
  • Metasploit - 1 / 5
  • Virtualization - 5 / 5
  • Backtrack - 2 / 5
  • Command Line - 5 / 5
  • SSH - 3 / 5
  • Putty (windows) - 3 / 5
  • FileZilla - 4 / 5
  • OpenSource Tools
  • How DNS Works (… and why it’s broken) - 5 / 5
  • Digikey, Mouser, Janesco, McMaster (LadyAda)