How do I do the thing?

A lot of questions and doubt flooded my mind when I accepted my current position two years ago. Coding was something that scared me despite incorporating it into various aspects of my life since I was young. Plus, it has always been one of those arenas that have scared off many geospatial professionals because of the learning curve associated with it. But, why?

Is it the code we inherit? The fear of not living up to a predecessor? The fear of failing? All of the above?

It doesn’t matter if you have never touched code or if you code daily; there is the constant fear of being able to “do the thing” and exceed the expectations handed to you. Nothing is impossible but we have deadlines to meet and sometimes despite what management, a user, or a stakeholder ‘needs’ there isn’t an easy fix. So how do you keep the happy medium between what you can, and are capable of, and what is needed?


  1. Take a breath, you got this! 🙂
  1. Use your resources: Use fellow colleagues (in the office and/or social media), StackOverflow, and library documentation (e.g. ArcGIS for Developers, jQuery API, Leaflet API, Mapbox API, etc.)
    1. Be ready to think outside the box. Just because someone says something isn’t possible, doesn’t make it true. There is always a way. You might have to really state your case, especially if you are going against the grain, but start by thinking in new, innovative ways.


      1. Determine your time frame: If there is something you know will have a greater return on investment or is needed, try to incorporate it but communicate all of your concerns or potential roadblocks with your stakeholders before proceeding.
      1. Next, break down the problem as much as you can. From my previous post #5: Break down e-v-e-r-y-t-h-i-n-g):

Coding is awesome in that we can fix small pieces to make an entire application better. For example, if our problem is that we need to buy more milk, let’s break it down:

Q1: How much milk do we need? A1: We need a gallon of milk.
Q2: How much money do we need to buy a gallon of milk? A2: We need, at most, $3.00 on either a credit card or in cash.
Q3: How do we purchase the gallon of milk? A3: We will walk to the convenience store down the street.
Q4: What if the convenience store doesn’t have a gallon of milk to purchase? A4: We can walk an additional five blocks to a larger convenience store.

Some of these questions could be broken down even further (ie: What kind of milk?) but you get the point. Breakdown each problem into individual components, for both your sanity and your code’s sake. To get going on this respect, start by writing out some of the processes you plan to take. Eventually it’ll become second nature. Trust me on this one.

  1. Set many small, realistic milestones based on these steps and determine what you need in order to accomplish them. It is important to set three or four small milestones instead of one large one to help you achieve your goals.
  1. Reward yourself when you hit those milestones by treating yourself (video).
  1. Lastly, but most importantly, don’t dwell on the milestones you don’t meet. We’re human – we need breaks (vacations, sick time and lunches) and some things simply aren’t feasible in the time frame we’ve been given. Keep note of these moments for the future but don’t let them overtake your thoughts.

The Right Way

A few weeks ago a colleague told me about his code structure and asked me how I structure my code. I responded with something I firmly believe: It doesn’t matter how my code is structured; What matters is what works for you and what you are trying to accomplish.

People are certainly not identical to each other and the same holds true for code. Just because we may have different ways to structure our code doesn’t make one way “right” and the other “wrong”. In a sense, this goes back to my previous post, Being You in that we are all unique. So if someone tells you it’s the wrong way, how do they really know if that’s the case?

Is there another way? Always.
Is there a better way? Maybe, but maybe not.

Before you (re-)structure your code; think of the impact it will have on you and the problem you are trying to solve. Just because someone is questioning you doesn’t mean they are right but do take their considerations to heart because their idea could make your work and goal more achievable.

But, Where do I start…?

If you are new to the development community and you are looking for some guidance on how to set up your code, get on the Githubs and watch others in the geospatial and development communities, make some forks (say what?), and be ready to learn! 🙂

Also, if you are looking for the basics in getting started with development, I recommend the following:

  1. Check out a page’s source code. While browsing the interwebs, check out the page source to see how pages are constructed and how other developers set up their code (right-click the page and select ‘Inspect Element’);
  1. Use multiple browsers. Learn how to use multiple browsers because they don’t always respond in the same way (e.g. Chrome, Firefox, Internet Explorer, Opera, Safari, etc.);
  1. Developer Tools FTW! Open a browser’s developer tools while visiting pages; you’ll learn a lot about how others set up their code structures and it is a great way to dig deeper into some code (Windows: F12, Mac: Cmd, Option, I);
  1. GUI vs. Source. If you post anything on the web using a GUI interface (e.g. a blog, website, etc.) switch between the “HTML” and “Source” tabs to see the code that is created while you are editing. You’ll learn more about what efforts are needed to make things work under the hood; and
  1. Start Coding! Make a homepage using your Github account. To get started, check out Github’s pages and the Pages Help. Not only will you get some coding going, you will see the effort needed from start to finish and you may even experience a few points early on to refactor your code as you add in more features.
    • Start small and get content into your page using HTML.
    • Once you are ready, add in some CSS to make that bad boy look awesome.
    • Once you are comfortable, add in some sweet JavaScript to add in some action.

Being you

“Sometimes it is the people no one can imagine anything of, who do the things no one can imagine.” -Alan Turing

Life is hard. People can suck, words can hurt and life as we know it can change in an instant as a result.

I don’t mean to get into a deep ‘life meaning’ discussion but I want you to know that you are not alone. I’ve been bullied, I’ve been put down and I’ve even been told that I am nothing. But I want you to know I have persevered; I am still here and I like to think I am a better person for all of life’s hardships.

So why am I telling the world this? Because when life is down it seems nobody is there for you. I want you to know that is not true. If you are reading this, I want you to know I will always be here for you as I hope you will be there for me.

But most importantly, this is normal. If you are different, which I hope you are, there is no doubt that life has been hard. People don’t like “different” and they expect everyone to fit into a box or machine and when we don’t, people can be rude and mean.

Which brings me to the quote at the beginning of this post. If you haven’t already, check out The Imitation Game. The film touches on the life and work of Alan Turing and a team of British cryptanalysts during WWII. Is the movie completely accurate to Turing’s life? It’s a movie, so of course not. But there are some great life lessons to take away from this film and I don’t think you will be disappointed with this one (plus, it’s an amazing story 🙂 ).

Just remember, you are unique and that’s a great thing. Those who do and think differently, as Turing said, do the things no one can imagine.

So give those haters a reason to sit down and shut up. But most importantly; never change who you are because you are beautiful. Now go do the amazing things you were born to do!

A Developer’s Toolbox

“No home is complete without a proper toolbox. Here’s April and Andy’s: A hammer, a half eaten pretzel, a baseball card, some cartridge that says Sonic and Hedgehog, a scissor half, a flashlight filled with jellybeans.” – Ron Swanson, Parks & Recreation (video)


While many of us laugh at April and Andy’s toolbox contents, the statement Ron makes is a valid one. We all need, in some capacity, a toolbox to properly equip us. Developers and non-developers alike, we need a specific set of tools to get our jobs done.

But just because we have a tool in our own ‘toolbox’ doesn’t mean someone else will use it in the same way, or use it at all. For example:

  • Do we all need the same tools? No
  • Do we all use the same tools? No
  • Do we all use the same tool in the same way? No
  • Will we use the same tools throughout our careers? More than likely, no.

Another element to keep in mind is that sometimes we need more than one tool to solve a problem. In fact some problems require the use of multiple tools together to solve a routine task. Check out the crow intelligence video below (an oldie but a goody):

So listing the name of tools I use is somewhat misleading. Will my list of tools help you? They could, or they could have the opposite effect. Also, tools can become obsolete over time – look at the Google Earth API.

But with these things in mind, below is a short list of some of the tools found in my toolbox, organized by price [Note: I use Windows as my OS both personally and professionally]:

  1. Notepad ++ (Free): Think Notepad on steroids; it’s simply amazing. A source code editor that supports a lot of languages (I haven’t found one that isn’t supported yet). Plus the creators compare it to ‘free speech’ and ‘free beer’ on their website; clearly you can’t go wrong with this product.
  1. OSGeo4W (Free): The Windows package of: GDAL/OGR, QGIS, GRASS, MapServer, OpenEV, uDig and others. From what I have used and seen I am a huge fan and it’s made my life so much easier. Some of the tools you can tap into with GDAL are incredibly powerful and can produce some amazing things, sometimes superior to Arc- products, plus it’s free. I am not sure about other OS’ and I am pretty new to the scene but if you ask The Googles, you should be able to get what you need.
  1. Eclipse IDE (Free): While I complain a lot about Eclipse, it’s a pretty cool tool. You can customize the environment in any way you like, including a whole suite of amazing plug-ins. However, a forewarning for beginners: it’s not the easiest tool to setup and anytime Java updates you may encounter some issues. But if you are willing to weather the storm, you will enjoy this product as a developer.
  1. Git (Free/$): When a colleague first showed me Github I was extremely weary of it but it’s been extremely useful to me both personally and professionally. I have been able to learn new tidbits and tricks and improve my overall knowledge all while meeting others in the development community. Git tools, specifically Github for Windows (Free), provide a way to sync your work with the Github community. Most of the Git tools are free but a few do have a small cost.
  1. GIMP (Free): An amazing raster graphics editor. GIMP was the first open source tool I ever used so I am somewhat biased. Overall, I find it much more usable than Photoshop and hey, it’s free.
  1. Adobe Illustrator CC ($$): An amazing vector graphics editor, especially for cartography and graphic design. I have tried to use the free and open source software, Inkscape but in my opinion, it simply isn’t the same as the Illustrator product. While I am very resistant to fork money over for something that has a free alternative, this is one of the instances I recommend going with the paid version.
  1. Adobe Acrobat Pro ($$): Love, love, love this tool! Whether it be for combining multiple documents, creating professional forms, and/or scanning documents and redacting private information (for reference). I do recommend getting this when you purchase a new PC, it’s usually a much better deal than the monthly pricing Adobe lists on their website.
  1. Esri ArcGIS Advanced ($$$): I don’t want to start an ArcGIS vs. QGIS debate and to be honest, I don’t have much experience with QGIS but since this is what I know, I am adding it to my list. This goes back to one of my comments above; as my career progresses this tool may or may not be on it but for now it’s on the list (please don’t send me hate mail). The package includes: ArcMap, ArcToolbox, and ArcCatalog among other items. Be ready to sell your first born on this product; it is quite spendy.

Monetary Guide:

  • $ Broke and/or young professional approved. 🙂
  • $$ A larger investment but worth it if you can afford it.
  • $$$ You better check (and re-check) your bank account before making this kind of purchase.

So tell me, what tools do you use?

The Nine Truths of Coding

I am sure some of you are wondering why I haven’t put in one line of code into this blog yet. It’s a very valid question and one I asked frequently a year ago, wishing more developers would incorporate code into their blogs but ultimately coding is more than coding. It’s about the basic fundamentals, using a tool to make something cool.

I’ll get to some coding soon but I truly believe the basic fundamentals are needed before you start going down the path of coding. Most importantly, it helps those who think coding is too hard. Of course it’s hard but so is learning to ride a bike as a child – and that didn’t necessarily stop you, did it? Think of all of the missed opportunities you could have in life had you chose to forego learning how to ride a bike.

So before you start writing off coding, here is my top nine truths of coding. I hope you enjoy (and please comment below or send me a message on the Twitters)! 🙂

  1. Coding is hard. I can’t stress this one enough and I explain coding as a rollercoaster. There are both highs and lows, the highs being higher than anything I’ve experienced in my professional career and the lows… well, they are low. Be prepared for both the highs and lows on top of any stress you may encounter – you’ll be a stronger, and better person in the long run but if you give yourself a lot of scrutiny those low moments will be brutal.


  1. Find a hero. I can’t stress this one enough – find someone you can go to for insight and who will provide unbiased advice. This person doesn’t have to be physically near you either; it could be someone from GitHub, Twitter or a meetup (see my previous post). Some may call this person, or persons their mentor(s) but this person is much more than that since they understand exactly what you’re going through. Latch onto these people and learn as much as you can from them.
  1. There’s more than one answer to every problem. As a geospatial professional this one wasn’t a new concept to me but I’ve seen other developers struggle with this one. There are so many libraries and tools you can tap into as a developer. Keep your mind open to new possibilities, even if you have a working application there may be a way to enhance usability or cut down on load time.
  1. Be prepared to learna lot. Something I eluded to in #3, there are so many different languages, libraries and toolsets. This is a really hard concept for someone who is new to development and just wants to get started. Don’t worry about being an ‘expert’ yet, in fact throw that idea out the window. Be ready to learn something new every day and build up your skillset.
  1. Break down e-v-e-r-y-t-h-i-n-g. Coding is awesome in that we can fix small pieces to make an entire application better. For example, if our problem is that we need to buy more milk, let’s break it down:
  • Q1: How much milk do we need? A1: We need a gallon of milk.
  • Q2: How much money do we need to buy a gallon of milk? A2: We need, at most, $3.00 on either a credit card or in cash.
  • Q3: How do we purchase the gallon of milk? A3: We will walk to the convenience store down the street.
  • Q4: What if the convenience store doesn’t have a gallon of milk to purchase? A4: We can walk an additional five blocks to a larger convenience store.

Some of these questions could be broken down even further (ie: What kind of milk?) but you get the point. Breakdown each problem into individual components, for both your sanity and your code’s sake. To get going on this respect, start by writing out some of the processes you plan to take. Eventually it’ll become second nature. Trust me on this one.

  1. Find a group of peers. While I would recommend finding a hero first, this is also of huge importance. When you experience a low point in your coding journey you will need your peers, who understand what you’re going through, to be by your side. Plus, you’ll be able to learn cool new things together.
  1. Get outside. A lot of people believe that developers sit at a desk all day. Yes, that happens and then we go crazy. If you are stationed at a desk all day, get up! Visit your coworkers, even if they aren’t fellow developers, go for a walk or grab a cup of coffee. The ‘experts’ agree, a change of scenery helps keep our creative juices going. I don’t have a link for this one but there has been a lot of momentum on this in the last month.
  1. Get rid of the BS, if you can. Sometimes it’s not possible to do this but get rid of any unneeded stress in your life – whether it be a task or person. If someone keeps blowing you off, they aren’t worth your time and they aren’t a good friend of yours. Remove/omit these things from your life and do it now, you’ll be much better off.
  1. Do something fun! I know, coding is already fun, right? But seriously, do something fun with your code, at minimum 2-3 hours a week. Whether that be doing a Twitter chat every week, finding a cool new library that does nothing relevant to the work you do (but could in time), grab a coffee/lunch/beer with a coworker to ‘talk shop’ or whatever it is that you find fun.

Which tool is the right one?

A tweet from Matt Kremer last month (listed below) sparked something greater with me that I wanted to share with others. Enjoy, and please comment on your own experiences, too!

Almost two years ago I was sitting with a colleague enjoying a cold beer and he mentioned something that has stuck with me ever since, “GIS is a tool, we use it to produce results but if we don’t understand what we need, it’s useless.

So incredibly true! As someone who has worked in many different sectors, I’ve applied GIS technology to many different departments, areas and projects.

Two years later, Matt’s tweet hit home yet again. As a developer – code isn’t the end goal, it’s a tool, like GIS is, to produce something great. Is it always the answer? No. But it could be.

What I’m getting at is – don’t think of the means to solve a problem, think about the end product (but remember that end product can change over time, too). Here’s a list of some of the questions I think to myself before initiating anything in my life:

  1. Why do this?
  2. What is the goal/purpose?
  3. Will I have help? Guidance? If yes, how much?
  4. What is the anticipated timeline?
  5. What do I expect to see when I’m done?

After answering some of these questions, we can better define the means, and which tools best suit our purpose and goals. Will we always use the right tool for the job? Not always but we can try our best to solve the problems that we face to find solutions – and I think that’s a pretty cool thing.

Lions, Tigers + Bears – Oh My!

My unofficial Lions, Tigers and Bears (oh my!) – aka Maptime, Github and Twitter – list based on an e-mail sent to a colleague interested in the GIS development and open source communities. Enjoy, all! 😛

  1. Lions (Maptime – MSP Chapter) –

Meetings are generally once a month on weeknights for two hours. I usually grab some #geobeers with good folk before and after. Good stuff; ranging from introductory to advanced topics throughout the event. Your spouse and/or kids could definitely come, too if they have interest in cool maps/cartography/geogeek stuff. 🙂


  1. Tigers (Github) –

For now just sign up and you can follow me if you want to see the ridiculousness that I do (forewarning – it’ll probably be obnoxious). Don’t worry about logistics on this yet, the biggest thing is to get on here and watch what people are doing, check out some cool things and other ridiculously fun things. Don’t worry about posting code if you aren’t comfortable, we’ll get there together.

  1. Bears (Twitter)

Sign up!!! And follow some cool and knowledgeable people/groups such as:

  1. Mapbox @mapbox,
  2. NACIS @nacis (Cartography-based conference in Mpls this Oct),
  3. Gretchen Peterson @petersonGIS (Cartography genius),
  4. Visual Idiot @idiot (this one is for fun more than anything),
  5. LeafletJS @leafletJS,
  6. CodeNewbies @codenewbies (they also have a Twitter chat every Wed. night – HIGHLY recommended),
  7. Lyzi Diamond @lyzidiamond (a cool geo-dev/geogeek),
  8. Maptime MSP @maptimeMSP, and
  9. MN GIS/LIS @mngislis

Also, this week in particular is HUGE – two amazing conferences are happening the Esri Developer Summit and FOSS4GNA. So follow the following hashtags (I’ve been keeping these browser windows open all day and refresh when a few come in) – #foss4gna and #DevSummit.