Tips for Dev Experience

I was asked by a software developer recently how to grow in experience, in the context of job applications, and I put my thoughts here as an encouragement to all software developers out there looking grow in their career. 

Two memes (and there are many like each one)

Software technology changes quickly, each company has their own software “stack” and established companies rarely try all the new things. It would be impossible, or at least difficult, to be a pro at many programming languages and all the frameworks available. However, and thankfully, these days it is possible to gain experience outside the job. “Experience” can mean two different things:

1. General knowledge of how software stacks (purpose of each part of the stack, how pieces talk to each other, pros, cons, tradeoffs, etc)
2. Specific programming languages. 

The nice thing is, one can build up the other. We use a lot of JavaScript at work and I have a few years working with other languages (#2), but my knowledge of software systems (#1) is pretty good so even if a company used a language I am not most familiar with (say, Python), I could work on a little python project and the concepts I know (#1) will carry me enough on a weaker language (#2). 

So basically, a programmer these days can grow a personal portfolio of real projects until their work experience catches up. Build a real system using a database, server and web page (free). Host that system in the cloud– all have free tiers. Put your code in a code repository (GitHub, BitBucket – both free). There are many blogs out there that walk someone through each of those things. Same for building a mobile app, or sourcing your data from an open API or contribute to an Open Source project. 

Not only does this add a few lines on the ol’ resume, it is real experience building a software system and can be talked about during interviews. Opinions are formed. Dialog is easier. New concepts are understood easier. One can legitimately say, “I’ve done that” or “I’ve built that” and it’s not guessing or BS. If a real project has been built, the pieces need to work together. Best practices are found on-line. The bugs have to be investigated. It is running on the cloud. It is a real system! Promote that during interviews; “this is what I did,” and one can have the confidence to do so because the system was really built! And you'll have the passion to talk about it because it's "your" system (and us devs love our own code : ) 

A step further would be to do it again changing a few pieces of the system:

• use a NoSQL DB instead of SQL (or vice versa)

• host on a different cloud provider (AWS, Heroku, Google Cloud, MS Azure)

• make the same web pages with a different front-end framework (VueJS, AngularJS, ReactJS, etc)

• change the server (Node, Python, Go, Java, C#)

Same system with a different piece or two will give a lot of experience, and prepare anyone a little more to jump into a new team or software stack.

That’s my two cents. Certified education and academia has its place, and real work experience is key, but knowing how software works in practice carries a lot of weight as well, especially in early and mid career. This can be invested in with some off-hours time, and is available to anyone who is interested. 

Picking a project that is meaningful or personal helps a lot here. Some people just like to learn and do tutorials for fun. Others, like me, need a vested interest before spending the time. A potential business idea would be cool, but even a hobby interest can be enough to actually enjoy the work. And if one does not enjoy the software language, or the grind, or the learning, that is actually very valuable experience as well!

Git connections while using PdaNet+

Sometimes we travel to my parents' place, who do not have internet or wifi. 

~Me, basically

We do have cell service, so working remote is possible. I use PdaNet+, a nice utility app for Android that turns my phone into a wifi hotspot on the MacBook. This works great for most everything that uses https. (Special ports, like a direct connection to Postgresql 5432 and the like do not work, likely blocked by phone carrier). This Wifi Direct connection on the Mac (Big Sur) requires a special proxy port, but then email clients and web browsers work great. 

However, git was giving me problems. An error like this:

$ git pull

fatal: unable to access 'https://***@bitbucket.org/***/***.git/': Could not resolve host: bitbucket.org

All other http works, but this does not? Aaarrgh!!

The fix: Set the proxy directly in git as well (same that is needed in WiFi Network settings)

$ git config --add http.proxy http://192.168.49.1:8000

(don't forget to `git config --global --unset http.proxy` when done). 

Now git works too. I'm living large on the edge of civilization : )

Edit: When using SSH Git (like BitBucket or GitHub required in 2022) the config has to be set another way. These lines were needed in ~/.ssh/config (and needed to be removed/commented when done)

ProxyCommand nc -x 192.168.49.1:8000 %h %p

ProxyCommand nc -X connect -x 192.168.49.1:8000 %h %p