A 2020 Look at Software Developers

Who are we? I think we often don’t have a good view, since most surveys struggle to get 1,000 responses. I know many surveys think that’s a representative number, but I think it feels low. I wish we’d get more data at SSC, but too few people participate in our efforts. The one place that seems to do a great job of getting responses is Stack Overflow. They released the data on their 2020 survey, and an article at Freecodecamp summarized some things.

Everyone looks at this data differently. For example, in the top loved languages, I see these: Rust, TypeScript, Python, Kotlin, and Go. Of these, I’ve really only used one. The most dreaded language is VBA, and I’d concur, but the most wanted language is Python. More developers want to use this than any other. Interesting numbers, but these seem more like emotional items, not practical ones. If we look at what pays the best, the Perl is at the top. I don’t know anyone that primarily works in Perl, though to be fair, I’m Microsoft focused. At least in the tech clusters, most have some relation to some SQL technology.

The database section is very interesting to me. This is my field, and I wonder how developers look at the world. The most loved db is Redis, and I’m not surprised. It’s key-value, blazingly fast, and relatively simple. I went through a couple courses at Redis University and found it to be a neat platform. SQL Server is 7th, with 50% loving it compared to 66% for Redis.  It’s also 8th in dreaded and 12th in wanted. Interestingly, while Oracle and DB2 are dreaded, Couchbase and Cassandra are up there. Redis is the least dreaded, though still 30% of developers dread this. My guess is that developers just struggle with databases in general and get annoyed by having to deal with them.

The other interesting data point in the results is about searching for a solution online. Just over 50% of the people are happy to find a link they’ve already searched on Stack Overflow. That makes me wonder if we aren’t really learning to code better, or if perhaps we don’t bother because we can just search. For a lot of programming research I do in R, Python, and other non-SQL places, SO is a great resource and often gives me a concise, useful answer.

Maybe this is the future of programming? Learn to search and what things to use, and don’t bother memorizing deep syntax or pattern specifics? I don’t think that works for SQL. We need to learn to be better. Perhaps this is why developers dislike SQL because it has few keywords and requires more programming skill to build efficient solutions. Those might be harder to search for on the Internet.

Most developers work overtime, but it’s balanced among the time scales. Only a quarter of people do this every week, which I think is still too much, but at least this isn’t the vast majority. I think 15-20 years ago that would have been different. At last 60+% are slightly or very satisfied. Still about a quarter aren’t satisfied with their jobs.

There are other interesting items in there, and if you are a developer, or you’re looking to grow your career, it’s worth spending a few minutes with the data, and looking at how you view the world compared to others. I don’t know that I’d try to follow the crowd, but I’d certainly think a bit about how I view the world compared to others.

Steve Jones

Posted in Editorial | Tagged | Comments Off on A 2020 Look at Software Developers

Delete a 2020 GitHub Repository–#SQLNewBlogger

Another post for me that is simple and hopefully serves as an example for people trying to get blogging as #SQLNewBloggers.

I have a lot of GitHub repos, sometimes just set up to test something. Recently I wanted to delete one, but most of the docs on the Internet were out of date. So I wrote this one.

The help docs say to find the Danger Zone for your repo. I didn’t see this as an item under Settings. Instead, I see this.

2020-06-09 19_35_56-Options

However, the docs talk about access, so I decided to check the “Manage Access” item on the left. I see options, and since this is a public repo, I see the “Manage” link.

2020-06-09 19_37_12-Manage access

This actually scrolls me down, which I might have figured out, but in my view, I didn’t see any obvious idea that there was more below the settings. Instead, I find the Danger Zone.

2020-06-09 19_37_54-Options

Here I can click “Delete this repository” and it’s gone. Well, it’s gone if I confirm I know bad things happen here.

2020-06-09 19_38_52-Options

Be super sure and super careful with this. Be sure you know what happens. If you do this to a private repo, forks go away. That could be really bad in an org.

SQLNewBlogger

If you build software, employers want to know how you build software. This post took me 10 minutes to write, and gives someone interviewing me the chance to ask me questions. How, why, etc.

You can do this for your own reasons.

Posted in Blog | Tagged , , | Comments Off on Delete a 2020 GitHub Repository–#SQLNewBlogger

Daily Coping 1 Jul 2020

I’ve started to add a daily coping tip to the SQLServerCentral newsletter and to the Community Circle, which is helping me deal with the issues in the world. I’m adding my responses for each day here.

Today’s tip is to enjoy trying a new recipe or cooking your favorite food.

I did this one the other day: https://www.tastecooking.com/recipes/garlicky-peanut-butter-cold-noodles-jif-spaghetti-recipe/

The family really enjoyed it.

Posted in Blog | Tagged , , | Comments Off on Daily Coping 1 Jul 2020

No Excuse to Ignore the Database

I’ve been writing, talking, and practicing DevOps for nearly 20 years. It wasn’t called DevOps back then, but in the early part of this millennium, I worked in a software team that embodied many of the three ways of DevOps.  We made small changes, we worked rapidly in short cycles, we adapted to our business needs, and we released often.

And we included the database.

At the time, this was a small team of about 15, and I had good control of the database processes, able to influence, debate, and demand our developers improve their skills regularly. We didn’t think about the database as anything more than one more challenge to overcome in order to build and release our software rapidly. Others feel that way as well and the ACM notes that a SQL database is no excuse to avoid DevOps.

This articles covers many of the things I’ve been preaching for some time. We use automation, we adopt good techniques, we instill discipline in our work, and we continuously improve. The article provides a few techniques for using deploying database changes. I do think some of these are good ideas, but as with many things, the devil is in the details. This is a high level look at what you want to accomplish, but the actual mechanism for making changes will vary, depending on your environment.

My employer is constantly searching for ways to improve database development, and we follow many of these techniques in principle. We recognize that testing and deploying changes needs to be easier and more reliable. As we build solutions, I think we’ve helped customers in many ways, however, my fellow advocates and I continue to preach a few things not in the article.

First, we need to continue to improve our code skills, which include data modeling. Moving faster doesn’t mean we get to shortcut good design principles. Second, everyone working on software touching the database needs to work closely together. The data is the most important part of this process, and we can’t afford to let anything happen to it.

I implore you to become better code writers, better software developers, and better team players. I also encourage you to look at DevOps as a set of principles, not as something you buy or install. Like much of life, adopting DevOps is a journey, just like your work with SQL. I’m sure that journey isn’t complete.

Steve Jones

Note: Podcasts paused this week as I have construction taking place at the house and nowhere to record.

Posted in Editorial | Tagged | Comments Off on No Excuse to Ignore the Database