We were using libsodium for encryption, it was chosen by the client and is intended to be client-side for very good reasons. I worked with management to harden the crypto past anything I had ever done before. Spare me that "101" stuff. Going all the way to abstractions like "business logic" loses essential points. I don't want to go from specificity to generality; read the libsodium architecture if you want to talk more about this.
I've written all I intend to about TDD. I have several articles about it in which my critiques are laid out, I'm sure you can find them. If you want to discuss it further, please do so there.
"Even Bill Gates." I've met Bill Gates. I don't regard him as much of an authority on the intricacies of software. He's a suit, not a developer. He wrote some code a long, long time ago and then he started making donations to universities to promote free market economics. and frankly, he's a mess.
Code reviews are rarely of any value, people come straight from the printer to the meeting and see the code there for the first time. Unless I am working on an enormous project I review every commit by every developer in GitKraken and ask questions. Code reviews are usually formatting quibbles. I see no value in pull requests.
14) I can manage my communications with others and I can regard someone as an idiot and not show it. "Never give an asshole a legitimate grievance" is a foundation for me. I was a hell of a lot more considerate than L ever was. He wouldn't even communicate.
You were not on the call. It was only seconds after L named the branch I was working in that he asked about it as though the conversation had never started. No I did not ask him. It was hard enough to stay on the call. It was like senility and there was no possible mitigation, no gap, nothing.
You like working without specs? I have turned down gigs because clients wanted me to work without them. This sounds like more of that backwards-is-better stuff there is so much of in the industry. But the project interested me and I made an exception.
My position of advocacy is that focus and concentration—Flow—are the foundations of good software work. If you think pair programming is software development then we are done here. It puts even ordinary concentration out of reach and it has led to so many mass resignations and put so many into therapy that my friends back in the USA tell me nobody uses or even mentions it anymore. I needed counseling to put the experience behind me and, this is very unusual for me, my mind is closed. I would end an interview were it mentioned in any context other than "we don't do that shit here."
Pair Programming is Appallingly Unproductive and Sadistic
It is truly hard to believe anyone can claim there is anything good about it
I am usually the sole developer on the back end: servers, database, IIS, and work well with the other side and with customers. I've never had a coworker who was harder to work with.
I've been a developer since 1988. I remember the days of single occupancy offices and one meeting per week. Before these methodologies came along and poisoned the well. "Stories" (spits).
And when it comes to agile etc. "They're doing it wrong" is a lame copout I've heard too many times. Agile = meetings = broken concentration = lousy code.
Thanks for your time.