I picked up an i5 NUC and webcam for the office on my own dime. It was one of the kits that you add your own storage and RAM to. At work we were doing Hangouts for remote employees and it was a weird dance with crowding around whoever got their laptop open first. The NUC is in a more central area and does Google Hangouts just fine. It is running Fedora Linux 27 and it works great. Besides a video conferencing machine, it makes a very decent workstation for anyone who forgot or broke a laptop or for visitors. Like some of the other commentators, we do our heavy computing on virtual machines either in our colo rack or on Amazon EC2. The NUC has plenty of power to run Vim, Emacs, or for some people Atom or VS Code. In fact, with 16 GB RAM and a Samsung 850 EVO M.2, it feels more responsive than some people's laptops.

It is possible to have too many unit tests. Especially if they are testing lots of internal functions. Mostly you want to just test the external interfaces and if the internal functions are working properly the external ones will too. And of course as you've found out automated tests are great but can never replace an actual person using the product. You need testers, even if it's the CEO and receptionist. Agile is not against design, btw. Spend some time locking down those external interfaces and then DON'T CHANGE THEM. Combined with unit tests only on those external things, you can develop really quickly by relying on the mostly static tests to catch regressions. Stick to it. Even if you find out your external interface design could be better, unless it's really screwed up STICK with it. Fix everything in version 2. And exercise more control during story creation to keep people on track. If something works already, keep it and work on something that is broken.

If you follow the Apple philosophy then anything that isn't available in the GUI isn't anything that you need to do. I've successfully used Fedora and Ubuntu without ever touching the console. I did need the console to run ping and view detailed network configuration. But honestly, doing those things is easier in a console even on Windows or Mac. A lot of the console stuff seems to be from 3rd party developers who don't put in the effort to do it correctly. curl URL | sudo sh seems to be all too common, when a downloaded RPM or DEB would install on a double-click just like a Windows MSI.

I think people still want big monitors / TVs, game controllers and keyboards. And the video hardware to run them at 90+ FPS. But I think these will move to wireless and the Desktop PC will become more and more a Home Server in a back room or closet. Some people will be content to use remote "cloud" systems but I think there are a ton of people who don't want to give up control of their media collections, especially the ripped and torrent stuff. I am always being surprised by people who aren't in IT but are running Kodi on Linux with 12 TB of RAID drives. Media users will want heavy CPU for transcoding, gamers for games, developers for virtual machines and containers.

Oh yes the "simple question." Like one I saw today (paraphrased), "I am using pthreads. Something is wrong because when my thread finishes I notify my main thread but it never gets notified." Oh yes. Like I can answer that. No, that question vaporizes in less than 2 minutes with 6 downvotes. Because it is useless.

Gary Wheeler wrote:

If you really want to impress us, build a steam-powered starship ;-P .

David Drake has steam powered star ships in his Leary novels. Of course, the water becomes steam because of heat from a fusion power plant. But still! Steam!

I like a good GUI too with a BIG emphasis on GOOD. Bad GUIs are horrible. That said... The command line is easy to use in script. This is very important when you want to say, automatically unzip and commit ten things or instantly repeat the last action. If you have a command line you can write a GUI. If you only have a GUI you have to hack the code apart to remove the GUI and create a command line version or add the necessary COM/DBUS interop. A GUI is difficult to make cross platform. A GUI is almost always two to three times as much data as the program itself. More to copy around and longer to start up. A GUI requires design skills and bitmap drawing skills rather than just coding skills. A GUI slows down development of the good parts because they can't be used without including that in the GUI. Command line you add a new verb or flag and you're done.

That's a bit harsh isn't it? Used in the right place, a trick like this could shave days off a long simulation run on a research cluster. Finding the right place to use something like this is always the hard part.

There will always be a job for software people. That program written by the AI? The AI is no more able to solve the Halting Problem than you are. It cannot foresee the entire range of possible problems and world interactions. So that accounts package it just wrote will need to be fixed when it has mysteriously slow performance on your new SSD storage. It might crash on the first Tuesday after a leap second. Things will need to be fixed when the database and the web frontend disagree on the proper UTF-8 encoding. And it'll probably only work correctly when you use all Microsoft, Google or Apple products of the newest revision. God help the office that has a mixture or has to support old Windows XP desktops! I foresee AI programming making the easy things really easy, leaving us to solve the difficult problems. As an example, CPU design software has made a lot of what designers used to obsolete. But it hasn't resulted in fewer engineers: they just spend their time designing even larger and more complicated chips.

Not very common, admittedly. I don't understand why. I suppose some people don't like the waste of vertical space.

Which is why this is better:

if (
something_longer_than_this &&
something_else_long
)

Use a code style that doesn't depend on tab size for alignment. Instead of lining up your second line of function parameters with the first line, put all the parameters on separate lines and indent each line. Etc. Then it doesn't break your layout when the tab size changes. Plus, it doesn't make your code lean way over to the right side when you use an especially long function name. And, it makes it possible to use a regular font instead of monospace. Weird, I know.

This could have been written because there is an annoying compiler warning with Visual Studio about coercing an integer to a boolean type. Quite a lot of useless code has been written to silence compiler warnings.

Yep. I would. I like targeting multiple platforms because it forces a certain mindset about portability. I find it improves the design and keeps the GUI more separate from the functionality. It also exposes the code to a lot more build environments which can expose subtle bugs. I like building for ARM, IA64 and PPC for the same reasons.