Posts

"Does it get easier?" Yes, but Also No...

Image
Image by Arek Socha from Pixabay It's complicated... "Does it get easier?" I see some form of this question asked a lot in beginner programming groups. I always struggle with how to answer this honestly and clearly, because the truth is not that simple. In some ways it does get easier, but in other ways it is almost always going to be difficult if you are advancing in your career . If you are a programmer and your job is easy for years on end, the most likely explanation is that you're in the kind of dead-end position that people try to avoid, not the kind of position people dream about when they think of becoming a developer. Most likely you are not getting better at being a dev, not working with new tech or solving new kinds of problems, not being given more responsibility, etc. etc. etc. I've seen some pushback from other newbie programmers on the idea that it could remain difficult past the initial learning stage. Notably I have never once seen somebody who...

How to Land Your First Dev Job: Develop Yourself, Market Yourself

Image
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 "...

2021 Goals and a 2020 Retrospective

Image
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...

Git. The WHAT and WHY Edition.

Image
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...

March-July book: Designing UX: Forms. Plus tales of pandemic work-from-home madness.

Image
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...

February book: Rocket Surgery Made Easy

Image
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...

What's in a Name?

Image
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 ...