Shambling Towards Perfection

Image by magnetme from Pixabay In the coding and tech groups I'm in, I see the same question asked over and over by folks who are just learning to code, finishing up a bootcamp, degree, or other training program, or who have been looking for that first job for awhile and not having any luck: "what do I need to do to get my first dev job?" There's a whole ton of info out there on this topic, but it's scattered all over, so I thought I would gather together the best resources I've come across and share them, along with a bit of context, to try and help everybody struggling with or just plain wondering about this. There are a lot  of things you can do to improve your chances of finding a job and hopefully shorten your job search. They are broadly divided into 2 categories: developing yourself and your skills, and marketing yourself and your skills. Note that you don't need to do everything on this list, nor do you need to do it all at once. This is an "

Well, my  2020 goals  didn't all get done, but then when I came up with them I wasn't anticipating a global health emergency to derail... Everything... So with the start of the New Year I figured I should revisit last year's goals and set new goals for this year. Image by Ockert Le Roux from Pixabay 2020 goals Finish rewriting apps at work. Try doing actual usability testing on at least 2 apps in order to determine if it's worth our while for future development. Complete UX/design training curriculum at work. Read at least one professional development type book per month. Finish 2 major e-textiles/wearable electronics projects by the end of the year. Finish up the nativity figurines I made in pottery class before Christmas. Finish 3 mixed media 3D printed/acrylic paintings by the end of the year. Things I'm already doing but want to keep doing include: Kick ass at work. (No false modesty here) Practice Spanish at least 6 days a week. Mentor CS students and women tr

Lately I've seen a lot of new/aspiring developers talk about difficulties learning git . I was confused at first, because there are approximately a zillion git tutorials out there. But then I started really looking at what people were saying AND what all those tutorials contain. The problem is most tutorials start out with "here are a ton of git commands to memorize", and this is not where people are having problems. People are having problems with "what is git, why should I learn it, and what does it look like to use it in a real-life project?", and those questions are largely not answered in all those millions of tutorials. So at the risk of redundancy, I'm going to attempt to address these questions in Yet Another Article About Git. First, I want to make it clear that if you want to be a programmer, any kind of programmer, you need to know git. You just DO. This is the short version of the answer to "why should I learn it?".  The medium length a

I started this book waaaay back in the good ol' days, BC. Before Coronavirus. And then the pandemic struck and blew up my placid dev existence. On Friday, March 13, 2020 at 4pm NMSU finally decided to allow us those of us who wanted or needed to, to work from home. I took the weekend plus 2 days to get my home office set up; I had a feeling this was going to go on longer than any of us thought at the time. That decision has paid off in spades as I was able to get a pretty sweet dedicated workspace set up, with a corner desk, my 2 personal monitors, my work monitor, my work tower, a printer/storage cabinet, and a new laser printer. Oh, and a nice office chair and one of those carpet protectors. Current me is very grateful to past me for having that forethought...  Anyway, I officially started working from home March 18. By that time NMSU was no longer "allowing" us to work from home by choice, but instead sending everyone possible home. In less than a week we had to move n

I had originally planned to read a book about form usability this month, but one of my goals for the year was to try out usability testing. Last month's book, Steve Krug's  Don't Make Me Think , convinced me to try, and we needed to go live this month with some Very Important, Highly Visible features on our internal portal that everyone in the entire department needs to use. Don't Make Me Think 's promises of immediate, valuable feedback on usability problems from doing usability testing convinced me that NOW was the time, hence the switch to Steve Krug's other book, Rocket Surgery Made Easy , which focuses on doing informal, cheap, and easy usability testing, and suggests what to try first when trying to fix the issues that are inevitably discovered during testing. It was an easy, fast read, so I was able to finish the book in time to use its advice to guide our very first usability tests AND fix most of the issues we discovered during testing before goin

Obligatory Shakespeare reference: What's in a name? That which we call a rose By any other name would smell as sweet. Software engineer, software developer, programmer, programmer analyst, systems analyst, code monkey... I always find it frustrating that there are so many different job titles for more or less the same thing. And that's not even getting into specialties (and sub-specialties!) like web, embedded systems, mobile, front-end, back-end etc. etc. If pressed I would say I consider myself a software engineer because of the sheer amount of studying I've done/am doing including that whole 4.0 on a masters degree thing, plus the wide variety of tasks I'm both capable of and currently responsible for (despite the school of thought that says nobody can be called "engineer" unless they've taken a professional engineer exam; the exam in question was discontinued due to lack of interest, so... ). Anyway that's what I put on my LinkedIn. But NMSU