Geek Speak

4 Posts authored by: Corey Adler

Another important tip from your friendly neighborhood dev

By Corey Adler, Professional Software Developer


Greetings again, Thwack! It is I, your friendly neighborhood dev back again with another tip to help you with your code education. I appreciate all of the wonderful feedback that I’ve seen so far on my previous posts( So You’re Learning to Code? Let’s Talk, Still Learning to Code? Here’s a Huge Tip, and MOAR CODING TIP! AND LOTS OF CAPS! ), and am grateful to be able to help you out in any way that I can. Although my previous posts have dealt typically with actually coding, this post is going to deal with something else. You see, I’ve been here trying to help you now for 3 posts, and I’d like to think that I’m doing fairly well on that score, but you should know that in programming, much like in other fields as well, there are people that mean well when they want to help you but will fail miserably when push comes to shove. The kinds of people who shouldn’t be allowed to teach at all—even when they are motivated and want to do so. When these people do come to your aid you’ll typically end up the worse for it. And so, to that end:




So what is a brogrammer, you ask? According to Urban Dictionary, a brogrammer is defined as: “A programmer who breaks the usual expectations of quiet nerdiness and opts instead for the usual trappings of a frat-boy: popped collars, bad beer, and calling everybody ‘bro’. Despised by everyone, especially other programmers.”


Now, before we get any further on this I want to emphasize that I am not singling out specific people. This is not a personal attack on anyone (in case any of the ones that I’ve met for some reason end up on Thwack, which I highly doubt). This is entirely a professional rebuke of the whole brogrammer mindset and attitude. It’s become more and more commonplace amongst entry-level software developers, and is one that can be highly toxic to those projects or people that are associated with them.


There are, traditionally, 2 problem areas that a brogrammer fits right into:

  1. Sexism
  2. Bad Craft


Let’s tackle these in reverse order.


What do I mean by “bad craft”? Oftentimes with brogrammers you will find an unwillingness to spend the extra time and attention to detail needed to create good code. Brogrammers tend to care about coming in each day, doing their 9-to-5 (not a minute more), and leaving to go have fun with their friends. They tend not to try and better their craft unless it’s absolutely necessary for them to keep their jobs (and beer money). Let me illustrate with an example: There exists a well-known company (name withheld for probable legal reasons) about which a former employee wrote the following:


[Company] is run on a tangled mess of homegrown tools, horrendously fragile code and the worst engineering practices I've ever seen from any company. There is no QA, code reviews aren't taken seriously, anyone can commit to master and push their code to production at any time…Brogramming is real and [Company] exemplifies it. It was the norm for bros to knowingly push buggy, incomplete, untested code into production after a few rounds of drinks then leave the problems for others while they moved onto another project.”


Or how about from this company:


“Once you're in, you'll be subject to one of the most cliquish offices I've had the "pleasure" to work in (I've been in IT for 8 years). The best word I can use to describe the existing staff: brogrammers. Definitely male-dominated. Every guy is an alpha male who probably rather go and lift weights, instead of writing solid code. The code base is a mess. Barely documented, sloppy, and basically changed on an ad hoc basis (if you ask about requirements documents you'll be laughed at). Everyone seems far too busy to do any kind of peer-review and coaching amounts to an irritated developer grudgingly taking a moment to help, and the help amounts to the developer doing it and basically saying, "there" and leaving.”


As someone who is starting and out, and trying to learn the basics of programming it is incumbent on you to find the best role models, who will help you learn and grow in the ways of the Force (i.e. programming). Brogrammers are the complete opposite of what you need. They don’t want to use good programming practices or have clean, understandable code. In such circumstances you would most likely be worse off after asking them for help.


Having said all that about “bad craft”, let me just mention that this problem is a drop in the bucket compared to the other problem—that of rampant sexism. Now, there is no possible way for me to fully cover all of the horror that is sharing an industry with these “people” in a short space such as this, but let me at least give you a taste of what I’m talking about. You see, because the above stuff that I wrote about bad craft? I wrote that 6 months ago. This next part? It’s taken a while. It’s been difficult to put my feelings into words that I can type without dry heaving into the wastebasket next to me at the thought that these “people” use the same tools that I do, use the same languages that I do, and pretend that their jobs are the same as mine. Let’s see some of the horror stories that I found in my research, both online and talking to my female co-workers.


  • Take, for example, a very famous social media company who decided to have an employee appreciation party. They even, it being an employee appreciation event, decided to let the employees vote and decide what type of party it was going to be. Not a bad idea, right? Pretty innocuous…until they voted to have it in the style of a frat party. The real cherry on top? Said company was embroiled in a lawsuit brought by a female former engineer for discrimination against women. How inclusive of them.
  • Or those times that my friend C, a fellow developer, would try to make suggestions to a client about the project she was working on and have them be rejected…only for said client to accept it once one of her male coworkers suggested it.
  • Or, as Leon sent me on Twitter, that time that someone spoke at SQL Saturday and received an evaluation form from someone that suggested that she could improve her speaking by wearing a negligee. (
  • Or the engineer who was asked whether her job at the company was to “photocopy [stuff]” and that she was “too pretty to code.” (
  • Or the whole ball of putrid, stinking mess that is Gamergate.
  • Or the women who have gone to conferences…and been groped. (
  • Or the developer conference in which a company sponsored a Women in Games lunch…and then had an after-party featuring scantily clad women dancing (
  • Or any of the tons of other stories that I found online while feeling my heart sink deeper and deeper, wondering how the heck we in programming and technology as a whole fell this low this fast.


The industry of Grace Hopper. Ada Lovelace. The ENIAC Programmers. Adele Goldberg. So much of the foundations for what we do every single working day of our lives we owe to these and other noble women who labored to provide us, their future, with this amazing gift. And now? We get excited that big tech companies like Google and eBay have 17% of their developer force as women! 17%. Since when has 17% been a big number? 17% is only a big number when you’re a 3rd-party candidate running for public office. For myself, I went through college only once having a computer science major class with more than 3 women in it, and that was only because it was cross-listed with the art department—which 2 of the women were from. We once could proudly say that nearly 40% of our graduates were women. Now? It’s less than half of that. Sure, there are tons of factors that can play into that, but none of them hurts more, none of them is quite as much a punch to the gut as brogrammers.


Because this is not who we are. This is not who we are supposed to be. We can and should be a hell of a lot better than this! We are the industry of outsiders. We are ones who played D&D and Magic: The Gathering in high school instead of trying to be like everyone else. We are the ones who talked about Science Fiction until people’s ears fell off. We are the ones who, when other industries demand suits, ties, and other more “professional” attire, said “No, thank you.” We were going to show all of them how we do things—our way. And yet we’ve fallen victim to this just like everyone else has. We let this happen to ourselves. We have no one else to blame. No one else that we should blame except ourselves.


The first step in solving a problem is recognizing that there is one. Brogrammers are a dollar store mustard stain on our industry, and one that seemingly keeps on growing. Their sexism as well as their lack of caring for the craft that we hold dear to our hearts hurts all of us who strive for better every day. Who think that these attitudes are obtuse, thick-headed, and generally uncouth. But even you, the programming novice can help out. Even you can do just one tiny little thing to help us fight this scourge of human garbage. Stay very far away from them. Don’t give them, with their pathetic, tiny little brains, the dignity of even acknowledging that they have some skill. And, if it’s not too much trouble, be sure to tell them all of this if they ever ask you why you don’t ask them for help. Because we don’t want them here. Don’t be quiet. Don’t be afraid to stand up against them. And don’t ever make the mistake of thinking that they have anything that we should learn from.




Let me know how you feel in the comments below, and please feel free to share your stories about these and other tech troglodytes either here or by messaging me on Thwack. Until next time, I wish you good coding.

Yet another tip from your friendly neighborhood dev.

By Corey Adler (ironman84), professional software developer

(With many thanks to my boss, John Ours.)


I knew it would eventually come to this. I knew I would inevitably have to deal with this issue, but I was hoping to put it off a bit longer. The thing is, I painted myself into a corner with my last post.


Well, here goes:


Always, always, FRAKKING ALWAYS declare your variables.


I don’t care if you’re using a language that allows for dynamic typing.




Why am I so passionate about this? It probably has to do with the fact that I’ve had to take a look and fix code in script files where variables were not declared. Those were some of the most difficult tasks in my career, simply because it made it harder for me to keep track of everything going on. It might be easy and simple for you to describe what each of your variables is doing, but what about the next person that’s going to take a look at it? As a programmer you always have to think not just about what you’re doing right now, but what might happen days, months, or even years from now.


So what about someone, like yourself, who is not a professional programmer, who is just playing around with the code? Wouldn’t that argument work in your favor (since no one else will be working on it)? NOPE! Because that next person could easily be you, years later, looking back over at some piece of code. Sadly, you can’t even make the assumption that you, who wrote the code, will still have some idea what that code does when you go back to look at it.



The best thing for you to do is to assume that the next person to look at it won’t have any idea about what’s going on and needs you to help explain things. The reason you should declare the variables is to help with the self-documentation of your code for future use. It’s a great practice to get into, and no professional experience is needed.


That’s as far as styling goes, though. The primary reason to always declare your variables (as well as why you shouldn’t just declare them at the top of your file), is because of a concept called implicit scope. Implicit scope is the idea that one should only declare their variables as they happen to need them. The benefits of this approach are twofold. First, it reduces the number of variables in your program that only appear in certain contained blocks of code. For example, let’s say that you have a variable that you only use inside of a for-loop. Instead of having that variable taking up space (both in your file and in memory) for the whole length of the program, you have that variable declared and used only in that for-loop. That way no one looking at the code needs to worry about other locations that use that variable since it’s clearly contained within a specific block of code. Second, it makes it easier to debug your code should the need arise. When you see a variable declared right before its first use in your program, you know that it hasn’t been used previously.  If you haven’t declared your variables, though, or you’ve declared them at the top of the file, someone (including you) who goes to look at the code later will need to check to see if that variable is being used anywhere else prior to that location, which can waste a lot of time and be a drain on one’s memory.


A third reason to declare your variables involves something in programming called coercion. Coercion is defined as automatically forcing one of the operands in a function to that of another type at runtime. Here’s an example of implicit type coercion, using JavaScript:

[ ] == 0; // result is true
0 == "0"; // result is true

So why, exactly, is coercion a bad thing? First of all, it requires each variable that you create to take a larger chunk out of memory than would normally be required. In statically typed languages, like C#, each different variable type is allocated a certain, fixed amount of memory, which would correspond to the size of the maximum values for those types. With coercion, all variables are treated the same, and are allocated the same amount of memory, sometimes way more than is necessary. All of this can add up in your application, potentially causing it to run slower.


A fourth, and probably more understandable reason for people not as well versed in coding as you, are the insanely weird behaviors that can occur by using coercion. Take this extreme example that I found at  Insert the following into the address bar of your Web browser (and replace the “javascript:” at the front if you have a browser that automatically removes it when copy-pasted):

javascript:alert(([]+[][[]])[!![]+!![]]+([]+[][[]])[!![]+!![]+!![]+!![]+!![]]+(typeof (![]+![]))[!![]+!![]]+([]+[][[]])[!![]+!![]+!![]+!![]+!![]]+([]+!![])[![]+![]]+([]+!![])[![]+!![]]+([]+[][[]])[!![]+!![]+!![]+!![]+!![]])


The result of this is an alert box with the name of the person who wrote the post at the aforementioned link. All of this is only possible through coercion. Let’s take another, simpler example of the weird behaviors that can occur when you allow coercion to happen, found at :

var a = "1"

var b = 2

var c = a + b


In a case like this, what would you expect the result of c to be? If you think it should be 3, then you’re a victim of coercion. The same goes if you think it will be “3” (as in the string value). In actuality, the value populated in c is 12. Adding a + sign to a (as in “+a + b”) will give you back 3 (as a number; not a string). Or how about the following example:

16 == [16]       

16 == [1,6]      

"1,6" == [1,6]  


So what do you think? The first one could be true, because they both contain 16, but it could be false since one is an integer and the other is an array. The second one doesn’t look right, but maybe that’s how an array of integers is expressed when printing them on the screen. Or the third one, which also doesn’t look right, but could be right for the same reason the second could be. The truth, in order, is true, false, and… true. WHAT THE HECK IS UP WITH THAT? It turns out that that is actually how JavaScript translates an array (into that string) and then comes back as true, since they now match.


One final reason for avoiding both coercion and the itch to not declare your variables involves programming architecture. Programming languages typically rely either on interpreters to translate the code to be run (like in Java™), or on compilers that do the same. What happens when your code is run is entirely dependent on those interpreters or compilers. Those things, in turn, can be highly dependent on the architecture of the computer that it’s being run on. Slight changes in either the compiler or in the architecture could drastically change the result of the program, even though it’s still the same code being run. What happens if, at some point down the line, someone makes an adjustment to the coercion system? How much code would that affect? Considering the ever-changing nature of the IT world we live in, that’s not a trivial concern. It’s also not a remote possibility either, with JavaScript due to receive the upgrade soon to ES2015. What will your code do when it gets upgraded?


So there you have it: ALWAYS DECLARE YOUR VARIABLES, EVEN IN DYNAMICALLY TYPED LANGUAGES. In the words of the Governator:



No, wait, that’s not right. Ah, here it is:



I’m finished ranting. Let me know what other topics you think I should touch on in the comments below, or feel free to message me on thwack®. Until next time, I wish you good coding.

Another helpful tip from someone who does this for a living

By Corey Adler (ironman84), professional software developer


Greetings again, thwack®. I hope my last post didn’t scare you away from learning how to code properly. What do you mean you haven’t seen it yet? Click here now!


When I began talking to my good buddy and Head Geek™ Leon Adato about more tips for you, the code novice, he stopped me right after I mentioned my first idea. “You know Corey, that’s a great topic,” he said. “You should dedicate an entire post to discussing it, not just a small paragraph.” Sigh. Fine. Here goes nothing.


Integrated development environments (IDEs) are your best friend

An integrated development environment (IDE) is an application that facilitates coding in any number of programming languages. IDEs tend to come with a variety of features, including a source code editor, intelligent code completion, compilers/interpreters (depending on the language), and the ability to debug the code as it runs.


In college, I knew a computer science professor who would not let her intro students use one of the better featured IDEs, such as Eclipse or NetBeans®, for her class. Instead, they had to use one that was nothing more than a text editor that could interpret Java™ programs. She did this because she wanted her students to learn the language syntax, to create class files without all the bells and whistles that would keep them from learning finger memory when they did. My reaction to her approach now is the same as it was back then, only more amplified: I think that’s an incredibly ridiculous way to teach programming – Java or otherwise.


Why? Because you aren’t going to learn the language any faster by breaking your teeth on it. All you’ll end up doing is frustrating yourself to no end. Professional software developers use full-featured IDEs all the freaking time. I’m a .NET developer who keeps a copy of Visual Studio® 2013 Ultimate on my work laptop, along with a bevy of extensions on top of it, including the popular ReSharper extension, which adds even more keyboard shortcuts and code completion features. It even gives me advice about good coding practices that I may have missed while coding.


It’s true. I already know the language. I’m not a beginner who should do it the old fashioned way to learn it. While that may be true, I’ve learned more about coding and languages from the helpers in my IDE than I ever did in class. For example, let’s talk about that whole intelligent code completion business. When I instantiate a variable (more on that in a different post) of a certain type, Visual Studio will tell me every different function and property that I can access on that variable. If they’re a baked-in type, I even get documentation about what each of them do! Why the heck would someone not want that? As previously suggested, don’t try to reinvent the wheel, which includes not avoiding the use of a full-featured IDE.


You know what else is cool about IDEs? The fact that they exist for pretty much any programming language in the world. I did a simple Google® search for a list, and found the following Wikipedia article that includes a huge list:


Not all of them are free, but most of the paid ones will still have a free version with some features. Working on .NET? (Hey! Me too! REPRESENT!) Download Visual Studio Community. How about with Java? Use the aforementioned Eclipse. It’s fantastic and open-sourced! Or maybe you’re one of those unfortunate souls who use Perl® and PHP (heaven help us all. Yes, Leon, I’m looking at YOU). In that case, may I highly recommend using NetBeans, which is free under GPL licensing! With so many options and features to make your coding journey easier, why would you ever choose to not use one?


Maybe Leon was right. This topic did deserve its own post.  Until next time, I wish you good coding!

By Corey Adler (ironman84), professional software developer


Greetings thwack®! You may know me as the guy who always pesters Leon during SolarWinds Lab™ ( What you don’t know is that Leon has been pestering me for quite a while to share some dev knowledge with all of you outside of Lab. I doubt a week has gone by without him asking me to contribute. I have finally acquiesced, and here is the result. For those of you networking types who like to dabble in the coding arts, here are a few tips to help you have a long and prosperous journey.


You are our new best friend…

Yes, it’s true! We’re happy that you’ve joined us. If you ever need any help, whatsoever, feel free to pester us. The more DBAs, network gurus, etc. that understand what developers go through, the better we’ll all be at communicating what’s needed to get our projects out the door in time. Imagine it in reverse: If a developer started learning and genuinely trying to understand what it is that you do, wouldn’t you encourage it? I have certainly come across a good number of IT people who’ve lamented how ignorant developers (and  their managers) are.  One job, in particular, had me interacting with the IT guys regularly, and they grew to like me because I wasn’t demanding ridiculous things for my project, I always listened, and I showed them that I wanted to learn the reasons behind what they were doing.


…and our worst nightmare

The reason for this should be pretty obvious. How many times have you seen a co-worker with less experience and technical knowledge than you successfully convince management to do something you know will end badly?  Or the person who doesn’t even have A+ certification who tries to solve a network issue instead of a CCIE? In both cases, I put good odds on something getting screwed up. Often, people who have just learned something think they know exactly how to use that new information. Trust me on this one: If you don’t have the know-how, don’t get involved. If you think that you know exactly what we need without talking to us first, you probably don’t.


For these first two points, the best approach, in summation, is for both sides to do something insane: COMMUNICATE!


Don’t try to reinvent the wheel

Imagine that someone wants to learn how cars work. They’re trying to figure out a good project that will help them dive right into the learning process. They go back and forth about it, and finally decide to create something that will change a stick-shift transmission into an automatic one. Is this person going to learn a lot about how cars work? Certainly! Is this going to be something practical that they will do on a regular basis? Probably not.


The same thing happens with programming. Chances are, someone has already created a tool that will help you do the thing you want to do, if not do it for you. Want to use CSS to have some cool styling on your Web page? Use Bootstrap to do it! Want to do some DOM manipulation in JavaScript®? Use jQuery®! Or how about setting up binding in your forms? Use Knockout! Does this mean that there’s no benefit to doing it the hard way? Absolutely not. It’s just unlikely that you’ll do it the hard way in practice. If you want to learn how to code properly, you should try and emulate those of us who do it for a living.


I hope this has been useful for you. Let me know if you want any more tips, tricks, or just general help. Remember the first point: I’d love to help you out! Until next time, I wish you good coding.

Filter Blog

By date: By tag:

SolarWinds uses cookies on its websites to make your online experience easier and better. By using our website, you consent to our use of cookies. For more information on cookies, see our cookie policy.