I agree - the term has become very loose - too loose in my opinion. The word is regularly being appropriated - maybe to make someone appear smarter than they are (?) but I don't really know the reasoning. I have sat in meetings where attendees hand out business cards that say "Systems Engineer", and I ask them the standard small-talk questions, like "Where did you go to school?" and "What was your major?". Regarding their major, I've heard everything from "Business" to "Accounting" to "Marketing" to "Management". They often start squirming and come up with some justification saying, "Well, I've been around engineering and engineers for a long time." Yeah, I've been around doctors a long time, but you wouldn't want me doing your vasectomy. :)

In my "travels", I have found another issue at work here leading to this bloatware. There seems to be this flawed belief that going out and buying a tool will magically make the real problems and inefficiencies of the business disappear - things like poor project management and processes, poorly defined or non-existent project and development workflows, lack of development conventions, non-existent or ignored review processes, no oversight, and on and on - a tool isn't going to solve these problems...they often just waste people's time. Often, the CEO/CIOs are pretty disconnected from exactly what problems the employees are facing and get "sold a bill of goods" by IT or a sales person (with zero evaluation by the employees who have the most "skin in the game") that some tool that he/she can buy will solve all these problems with a stroke of a pen to a purchase order instead of buckling down and doing the real work needed to create an efficient working environment and a functional business.

I have one of the electric standing desks from Vari. I vary the height of the desk from the seated position to the full-standing position at least twice a day (usually more) to get rid of leg stiffness caused by sitting for long periods of time. I'm pretty tall (190.5 cm = 6' 3"), and I find the highest position of the desk (123 cm = 4' 0.5") comfortable. Spec's now say that the desks go up to 128 cm (4' 2.4") max height. Have a small PC and two monitors, plus some books - it's pretty stable, but I wouldn't call it "rock solid". I'd recommend getting an industrial, padded mat to stand on for additional comfort. There's also those VariDesk converters (VariDesk 36) - had to raise it to it's maximum height and it was still a little short for me on the standard desk it was placed upon. Again, I would say it was pretty stable, but not "rock solid" and shakier than the full-blown electric desks. The do have the VariDesk Tall 40, but when I was looking, the reviews were not great, stating the desk was unstable at max height and the mouse/keyboard tray wasn't very ergonomic. Hope this helps.

If the project is fairly significant in size with multiple .c and .h files with many functions, I will often turn doxygen (with graphviz) loose on it. Even though the code may not have any doxygen tags or doxygen-compatible comment blocks to generate function and API documentation, it can still give you an idea of "what calls what" in a graphical context.

You are asking some great questions here! 1. Ubuntu distro, typically later than 16. 2. I do development using an Oracle VirtualBox VM running on Windows 10. I like the ability to manage separate VMs for separate development environments and always save both an "O/S only" VM as well as a "O/S + development tools" VM. I usually do full clones of the "O/S only" for build and deployment testing and use the "O/S + development tools" to create new development environments for separate projects. Full clones eat disk space like nobody's business, so you need a good hunk of disk storage. 3. I use...wait for it...Eclipse for editing and the GUI debugger (which is just a GUI riding on top of gdb). I often hear bad things said about Eclipse, and I have to agree, some of them are justified, but I like the things an IDE has to offer even though Eclipse ain't great like GUI debugging, the code indexer so you can right click on a variable or method and it will take you there, etc. It often takes a while to get Eclipse configured to do builds and debug (in both C++ as well as mixed C++/Python where Python is the typical entry point) and can be frustrating. I've had a lot of issues with the indexer picking up dependencies. 4. My build model typically consists of cmake with hierarchical CMakeLists.txt files. cmake has a generator that can produce eclipse project files via the -G"Eclipse CDT4 - Unix Makefiles" option, which is handy and seems to work pretty well, but honestly haven't tried it on the latest versions of Eclipse. One key thing you have to account for is that the generator (at least in the past) doesn't like a folder structure that stores build files in a subfolder lower in the directory hierarchy, e.g. doesn't like ~/username/MyProjects/SoftwareProjectA/build, so you have to get cmake to create the top-level Makefile directly in the top-level of the source tree, i.e. ~/username/MyProjects/SoftwareProjectA. This will allow you to debug your code using the Eclipse GUI front-end to gdb. 5. g++. Basically, go to source tree and run "cmake -G"Eclipse CDT4 - Unix Makefiles" -DENABLE_DOXYGEN=$BUILDDOCS -DCMAKE_BUILD_TYPE= -DCMAKE_INSTALL_PREFIX= .", then run "make -j4 install". 6. I typically use the Eclipse GUI-based gdb debugger, but this can be tricky to set up sometimes, but worth it. 7. Interface to github is usually done through Linux command-line "git". 8. Playing poker with anyone whose first name is preceded by a city, e.g. "Minnesota Jim

"Let's take this off-line." Either (1) I don't care what you have to say, or (2) tabling this issue in the presence of others is going to be embarrassing for me.

When I read the subject of your post and the first paragraph, my knee-jerk was "learn Python first" then "learn C++", but it appears your advice is focused on web development. Web development will show the fruits of your labor pretty quickly and that may motivate you to "keep going", no doubt about it, but I feel that Python also does this to only a slightly lesser extent. It is interpreted (no need to compile), has a lot of features to play around with (GUI, client/server, parsing, files, text processing, AI/ML, and on and on...) to make neat apps and games while also teaching concepts like object-oriented design (OOD), program structure / modularity, and multi-file projects and organization. C++ will layer on top of the OOD and multi-file project concepts while teaching new concepts like pointers and understanding the compile/link build process via gcc/g++/Makefile's, etc. Another path I would consider is maybe Android development (through Android Studio) - I'd lean towards Kotlin, but Java has more general use, so I'm not writing that off. Again, you can see the fruits of your labor quickly while making cool little apps on your Android phone or tablet.

@willichan The unfortunate reality of the public education here in the U.S. is that in many school systems, teachers are grossly underpaid. I have heard of teachers having to go on SNAP (government program to help people buy food) and with the constant cuts to education budgets, teachers often have to dip into their own paychecks to buy pencils, notebooks, and other baseline classroom materials. They are being asked to do more and more with less and less resources. Thus, due to the the poor pay and the poor support teachers receive, many who want to be teachers go into other fields and unfortunately, those that do become teachers tire of not doing the job they were hired to do, i.e. having to be parents, social workers, and psychotherapists to the students in their classrooms (due to poverty/hunger/family problems) before any educating can be done. The difficulties of attracting and keeping talent in the field has been going on for a long time. Turnover puts pressure on the schools and often have to hire out of desperation - "anybody is better than nobody". It is a "tough sell" to ask someone to go $100+ into debt for a college education only to get out and be poorly paid in a system that is poorly funded.

Not sure if this is in violation of your request to find a book that doesn't treat Kotlin as an alternative to Java, but thought I'd share nonetheless. Neil Smyth has a book (here's a preview: https://www.ebookfrenzy.com/pdf\_previews/Kotlin35EssentialsPreview.pdf) that does focus on Android development but has pretty good coverage on Kotlin (Chapters 11 through 17). You can use the Kotlin on-line playground for experimentation = https://try.kotl.in. Neil Smyth and his publisher seem to be pretty good about refreshing it as new versions of Android Studio come out. I have the 3.3 book and since then, there's been 3.4 and 3.5; I assume that 3.6 is coming soon.

Also late to the party...long-winded too :) And, good luck on your job search! TL;DR - The single act of purchasing new tool is not going to solve an organization's problems. One must set up conventions and workflows for the tool to optimize team collaboration for the organization. I have found in my "travels" that there is a misconception typically at the decision-making-level in organizations, that these types of tools (GIT, SVN, VisualSourceSafe, Sharepoint/Confluence, JIRA, Wikis, and bunches of others) and the features they provide, once purchased, make all your problems go away without any additional work. The flawed assumption is that the tool forces a specific workflow and thus forces team members to use the tool in just one way and by doing so, creates a single organizational structure for the data to be stored, which we all know is not correct - instead of the desired/assumed "file cabinet" for data (project docs, source, etc.), these tools become "junk drawers" (often referred to as the "wild west") where teams don't know what data is where, what is the latest version, identical doc's are stored in different locations/folders causing data coherency issues, nobody knows what is in the master/trunk branch (or tags or any of the other branches) - and it gets worse and worse as time goes by. The key to team success is, once the tool is purchased, one or a few people build up a moderate level of expertise so they know best how to use the tool then create (and document) a structure (branch definition for source tools, folder structure for doc tools) and workflow that works best for all the organization's requirements, then get buy-in/agreement, and put in the constructs (like varying access rights per group) prior to its use, and police it's use (which can be time-consuming) during its use. Mind you, for those that do contracting, you are often forced into the customer's source control/configuration mgt structure - sometimes a good thing, sometimes not. In agreement with others on the post, using a source control tool like git/GitLAB/BitBucket/Subversion for documentation control is not a good idea - Subversion/Confluence tools are more appropriate. I find source control tools deal best with text-based files (like code), but not well with binaries (like MS docs, etc.) wrt version control. Since I work for a small company, we have shied away from those complete solutions from Atlassian that are costly (JIRA/Confluence/BitBucket). We do use Atlassian JIRA for tasking/bug t