LocalMan

1. Retired. Mostly I read and surf the web. Take care of my health.

2. I left because I got old. Twelve hours of concentration just isn't worth it any more.

Attachment to a leader and/or parent seems to be a deep part of human personality. Especially in the first decade or two of life. I suppose a teacher-at-the-front could be replaced by a soft robot. But that's not a really large change in the method of education.

I do remember when learning calculus that I didn't really know integration and differentiation until I'd worked through a dozen or two of the homework problems. I could understand in class and nod my head, but would not be able to use that knowledge until I'd ground through enough example problems. That paradigm seems to be true for a lot of technical subjects and must be a result of the nature of human cognition.

And the world is getting even more scientific, more technological and more mathematical.

And those who teach writing emphasize that it is necessary to write a lot. A whole lot.

Recently popular has been the idea that to master any subject whatever requires 10,000 hours of practice. That idea has been attacked and taken down a peg, but not defeated; practice alone is never enough.

Attachment to a leader and/or parent seems to be a deep part of human personality. Especially in the first decade or two of life. I suppose a teacher-at-the-front could be replaced by a soft robot. But that's not a really large change in the method of education.

I do remember when learning calculus that I didn't really know integration and differentiation until I'd worked through a dozen or two of the homework problems. I could understand in class and nod my head, but would not be able to use that knowledge until I'd ground through enough example problems. That paradigm seems to be true for a lot of technical subjects and must be a result of the nature of human cognition.

And the world is getting even more scientific, more technological and more mathematical.

And those who teach writing emphasize that it is necessary to write a lot. A whole lot.

Recently popular has been the idea that to master any subject whatever requires 10,000 hours of practice. That idea has been attacked and taken down a peg, but not defeated; practice <i>alone</i> is never enough.

Writing code in a commercial IT shop in the late seventies, the manager though he was progressive since he guaranteed that we could get as many as one compilation per day. We'd submit punched cards and get back the card deck and a compile listing when it was done.

Hardware was less reliable, occasionally coming up with the wrong results. One time the result was wrong because the printer had printed the wrong digit! I'd spent hours desk checking the code only to find the code was right. So I ran it again.

It was much more normal for managers to really not know what a computer really is. This included programming and IT managers. One very accomplished boss asked me, in a meeting, how long it took to write a program. What kind of program? I asked. Oh, a general program. That put me in a no-win situation. If I said a year, he'd pop a cork and get all red-faced. If I said two weeks, he'd hold me to it no matter what the program was supposed to do.

I got old and retired.

I've written many tens of thousands of lines of C, but retired 15 years ago. The two best books I know are:

1. C: A Reference Manual, by Harbison and Steele. https://www.amazon.com/Reference-Manual-Samuel-P-Harbison/dp...

2. The C Puzzle Book, by Alan Fueur. https://www.amazon.com/Puzzle-Book-Alan-R-Feuer/dp/020160461...

Harbison and Steele has much better explanations than K&R. The Fueur book taught me a lot about C declarations. Declarations are that part of C language that is them most unnecessarily difficult.

You asked about a slightly different question, best practices. But in the real world you'll run into a lot of code that practices below that level.

One trick that works well for a limited set of situations: When reading a math or science textbook chapter, read the questions before the text of the chapter. The keywords in the questions will clue you in to the keywords of the chapter.

I'm pretty sure those M3's are around-the-ear. Unless you have gigantic ears. I'm wearing the M1 right now and it's around-the-ear.

If the company goes belly up that can be a good point for you. You left "Because it was becoming clear the company could not survive." Don't put all the blame on the managers, put a lot of blame on their competitors and customers. If the company is alive but on the ropes, the same tactic can be used.

I've been using Lastpass for years now. It's good but not perfect. Occasionally I have to fiddle with it. There are a few web sites that Lastpass can't deal with. I opt for big passwords so I'm sure it's more secure than trying to use my memory and/or some ad hoc scheme.

I haven't done an organized comparison of password managers.

Programming languages are like culture. If you're embedded in one then moving to another sometimes seems like a maze of funhouse mirrors.

I once had the misfortune of changing from an Algol environment to a Cobol environment. After a year I'd gotten over my revulsion and became fluent and productive in Cobol.

It's like saying English has lots of irrationalities to it, which is true. But if it's your mother tongue and you're fluent that doesn't matter.

Go is not impaired. Go involves a set of sophisticated choices for software engineering, not for computer science research. If you're going to have many millions of lines of code and some shifting around in your staff, you don't want tricky code that takes a long time to figure out, or that obscures functionality, or that obscures bugs.

The most fundamental things in learning to make software:

1. Alternate writing programs with classwork or book-learning. Back and forth.

2. Learn a programming language that a friend knows, so you have a place to get on-the-spot help. Ideally, somebody sitting next to you.

3. Have a computer available. Almost any home computer will do, no need for something expensive. There's plenty of free software you can download, free tutorials, free books...

4. There are cheap classes at some nearby community college or something like that. Finding the time is harder than paying for them.

5. The most important first courses are about a particular programming language, like "Python Programming 101".

6. The most important second courses are probably "Algorithms and Data Structures" and "Computer Architecture".

Google Keep for notes, recipes, shopping lists on my Ubuntu desktop and my Android phone.

The one thing you probably haven't been doing is having friendly work-oriented talks with your boss. A couple of times a week you should have been raising some easy issue just as a "heads-up" so the boss is up to date.

The idea is to break down the social barrier between you two and make sure he knows you, feels relaxed around you, and knows you're competent. A related important goal is to make sure the boss knows that you two can work together as near-equals as part of a team. That's what being promoted really means, from the boss's point of view.

You've run into a colleague more of a predator than an engineer. I've also been pushed out this way and was foolishly resting on my technical laurels.

Of course, the optimal way to respond to this is a contradiction: Raise a big stink, but secretly. This is not easy. I think the history of the "Tempest" security bug should be re-read every few years.

Your description of git raises a 'code smell' with me. I've found git to be far too complex to rely on. No, I don't have a replacement for cooperative development, but the thing is a bug trap (it leads you into complexity, making errors, and so on).

And therefore you learned that wisdom can be most obscure.

70.17 years: Last big thing was the programming language Go, a few years ago.

    The last thing was differing opinions of Maimonides and Yehuda Halevi on primeval substances with regard to Creation Ex Nihilo.

    The very last thing was that the apartment next door is vacant and available for rent.

    The very very most recent thing is that I feel like answering this question.

For a real software developer, PHP is a horrible language. And Javascript is almost as bad.

The software tools to help you build and deploy are also a painful mess. You'll have to test on multiple browsers running on multiple operating systems.

It's just a matter of a week or so of overcoming the cultural shock. But you'll have to schedule it in.

Paul Graham says to do it all in Lisp. Most people don't.

Learning Fortran II programming in 1965 on a super-computer at a local university. It had almost a megabyte of memory!

Actually, it was a CDC 6600, which had 131,072 words of 60 bits each, which is kinda the same as nearly a megabyte. I was so impressed that the number 131,072 is still etched in my brain.

Work with friends or whatever to find a new position before you end the one you have.

Unemployment is very depressing. Avoid it. One week or two is okay.

Google Keep is free, has multiple subsections, and automatically syncs between my smartphone and my PC with no intervention on my part.

To cool summer bedrooms, blow the air out the kitchen window, and open the bedroom window. This will draw cool night air in the bedroom window. You may be sweating at 7 PM but you might need a blanket at 1 AM. This works brilliantly. And putting the fan out the kitchen window means the bedroom is quieter.

To heat winter rooms that have an underpowered radiator, blow the fan onto the radiator. The job of heating the room is the same as cooling the radiator. This works very well but the room downstream (on the steam line) will be getting less heat. In practice, that was the neighbor's apartment. The freezing neighbors complained to the landlord who eventually tracked it down to my place. Vigorous discussions ensued.

I also discovered that a HEPA filtration unit, even sitting on the floor, helped my allergies a lot. It was not cheap, but when I find my nose running again, it means that something had turned off the filter. For years I had thought that HEPA was a scam. Not so.

As you get older, it gets harder to learn new stuff.

I dropped out in 1971 for reasons similar to yours. I am now retired. I've supported myself by writing software since the 1970's.

Dropping out has cost me several hundreds of thousands of dollars. I don't know how many. Lots of companies pay more just for having a degree.

Consider transferring to a cheaper and/or easier school. You'll have more time to yourself, which is often a good thing. Unless you're actually depressed.

If you're interested in CS, math is almost always useful. I wish I'd had more. Most of the topics you list are research topics only available to research-level academics.

Changing schools is the one thing I regret not trying. Another thing to consider is to change girlfriends. Or find a better one. That can certainly impact your overall view of life. In other words, don't ignore the social aspects of choosing a school.

In the 70's through the 90's I had to contend with management that was often quite stupid. And quite often did not even know what a computer really was. You can avoid situations like that more easily if you have a degree.

Consumer demand is endless. The more they have, the more they want. Machine Learning, or whatever it turns into, will just expand the opportunities and the requirements.

1. Many managers and customers really do not know what a computer is. At all. We know they don't understand code. Many don't even understand data. This problem very slowly dissolves over the decades, as the populace ages and gets replaced.

2. Personalities matter more than technology.

3. Don't let people drive over a cliff, just because it's their responsibility. Remember, you're in the same car. In a matter of life and death (of the project, or the company) grab the steering wheel. Of course, you'd better be sure you know what you're doing.

4. Out of desperation, some people will sabotage you and then blame you for it. Sometimes there is nothing you can do.

5. Always maintain a good working relationship with the person you're working for, whether a manager or a customer. Chat more often, even if it is uncomfortable. Especially with idiots.

6. Some people will be afraid of you, if you have greater expertise. They need to be flattered.

7. Seek out and learn from those who know.

8. Notice I said nothing about technology.

--------------------------

Beware the changes in technology. I spent decades in an environment where saving a few bytes mattered, and C compilers were just okay. The coding style I developed is now obsolete in the era of gigabyte memories, and too hard to read. Change with the times.

NYTimes.com elderofziyon.blogspot.com Newyorker.com

I rely on Chrome and Firefox Bookmarks. But I have too many (thousands) and find that Xmarks doesn't help all that much.

I was one of 7 people coding one of the 7 different real-time sensors for a large networked product. Another team was programming the central network manager and data processor.

The project was late and there was a daily-charge penalty clause in the contract with the customer, a very large company. A long enough delay could wipe out all the profit from the project. So engineering management told the programmers to suppress all signs of runtime bugs, no error messages, no halts, just slog on, bugs and all.

I objected, nobody paid attention. For my sensor, I had it scream bloody murder (on the diagnostic console) for every runtime problem it found. So I could fix it. The rest of the team followed instructions.

My unit was debugged, up and running, a year before everybody else. If the whole project would have been ready, the profit would have been reasonable. In a whole-team meeting,near the end, I asked the testing team if they had found any bugs in my unit. They asked "What's that?". They didn't even know its name. Suddenly, I was a hero.