externalreality

The only criteria I have for good code these days is "Does it work", "Can I understand it". Everything else is a good IDE's command away for being willed into reality. So I really don't spend too much time on the "good" code debate like I did as a teen reading "Clean Code" and GOF books. I actually wish I could have that time back, I would have read, in their place, books on type theory and OS design, Posix, in other words things that actually help me build stuff and get things done and that I subsequently had to read later. Undo the damage done by the "good code" people that have me thinking about stuff that nobody cares about. Take a month off, read a book on game design in opengl, and write a cool robot simulation or something and remember how much more gratifying that is than writing a small do-nothing program just to try out some useless design pattern that doesn't scale beyond micro-examples.

There is so much varying lit out there on how to write good code that I am surprised that I am surprised if even 2 programmers can truly agree on what good code is. So Again, I'll say that "good" when it comes to code should be equivalent to "easy to understand" and "does the flow of text match the flow of program execution" in other words "is it easy to understand given I am familiar with the problem domain".

Why these interview processes act as if candidates are going to be designing graphics engines from scratch for graphics hardware extracted fr om a downed alien spacecraftis beyond me. We just really be testing their ability to sort through a bunch of legacy OOP designed by people who are so board with the project domain that made of bunch of bad abstractions and used every new OOD technique in the books when a handful few procedural functions would have sufficed.

Funny because I don't think its small teams or a particular programming language that leads to great productivity. You don't have to look very far or far back to see teams, of various sizes, pulling off some amazing stuff with assembler and C. The key to productivity is a lot simpler, and independent of software development. Its a sense of responsibility, interest, and dedication.

In a small team that is using small talk the responsibility might come from being on a small team with a lot of lifting to do, the interest might come from having fun using a language that you like (regardless of the language), and the dedication might come from the promise of getting in early on a promising venture - hence the small team. All of these things add up to hyper-production.

If you can establish those three things, somehow, with a large team I don't see why hyper-production can't be achieved. Unfortunately modern project management for large teams seems to rely heavily on techniques that rob developers of all three qualities mentioned above in the name of so called "agile" and in pursuit of some fictitious software assembly line.

Those who are in favor of unit tests have one big weapon on their side of the argument and that is simply the word "test" "how can a test be bad?, right?"

1) Don't think you are the only one who understands these principles and realize people are going to have differing opinions on what is the simplest thing that can be done.

2) Just because you don't understand it doesn't make it complicated. If you don't understand something another is talking about try to reserve your judgement as to how simple (or not simple) it is until you actually understand what is being said.

3) Don't over do it with this advice. Sometimes you need to add a bit of complication to make the big picture easier. "A thing should be as simple or as complicated as it needs to be nothing more".

Yes, sometimes code is loaded with all kinds of indirection that usually comes from OO programmers outsmarting themselves with all kinds of implicit polymorphic dispatch and unnecessary design pattern legacy. This is why its important to ask someone familiar with the code to give you a rundown.

1) Centralize all of our calls to other code in one place. 2) Share response values from each step with other steps. 3) Clearly delineate the order of steps in our code. 4) Make our code more maintainable and extensible by avoiding nested spaghetti code.

I think test code should be the clearest, easiest, most lucid code. Even at the expense of code that in other contexts may be considered boilerplate or redundant. Test code serves a different purpose than production code and is made to be rapidly modified, quickly and dirtily refactored, and very easy to understand, and to be exceedingly clear as to what cases it is actually performing a run-time test on. Often I see authors writing test code as if the test code itself is built to be maintained and reused. In some cases that is true but generally not when actively developing a system.

Where does it say that. It actually says the opposite quite clearly if you cared to post the whole quote and not just what supports what you would like it to.

> They addressed one of the issues with a compile step, eg slower feedback loop.

Can you explain to me how faster feedback from static types that they, a concept which the article reiterates again and again, leads to a slower feedback loop. Clearly the article and many more like it say that the feedback loop actually speeds up with static analysis since you don't have to run the code to get the feedback.

I'm not sure if you actually want to objectively reason.

Bad form sir, bad form.

I'd say python is about as popular as Java and so I don't see companies investing a bunch of money to make Java programmers more comfortable when they could just hire an army of Python developers if they wanted to. I just think they see value in the static analysis that types provide. Read about why Facebook added types to PHP they don't mention your hypothesis.

I don't mind programming in languages with dynamic type systems. I find it just as fun. But I do think its easier when there is a way to easily keep track of the type of thing being operated on. I mean the data is what is actually being operated on, the more I can tell about the data from reading the code the better. The most difficult systems I have ever worked on were the ones where unshaped globs of data were being shuffled around in hash tables and heterogeneous sequences. I would always have to use the debugger to find out what was going on at a given point. The code was dispatching on value and type. It was rough.

What do you mean by interfaces?

But then this is an argument that I don't have much time for and too much time has been spent on it already. Lets just say that if there are many major companies that felt the need to invest in a type system for a popular languages that don't have one, then there might be something too it.

I am pro gun control but it is a little known fact that gun control was quite strict in 1930s Germany during the rise of the Nazi party. The point is that hate leads to mass death not weapons. If it wasn't an assault rifle it would have been a series of home made explosives and small arms, or 3D printed weapons, or a gang with swords and bats blocking exits. Stop the hate, don't pivot.

The New Zealand government should mandate anti-bias, anti-hate, diversity training for all government and private employees. Once per year, since there is virtually no education on the topic. Many people get bitter when they hare to take such training. I mean would the government let people get into a car without any training but people are allowed to hurt other with their bias and bigotry. Its a fact it happens. So why not try to stem it. Instead we pivot to gun control as if that is going to remove all hate and stop the problem.

When people say "Collective Ownership", they usually mean no one person is directly responsible for a body of code - and that is supposed to be a good thing. When you walk into a shop with this philosophy and have a question about the code you will find that you usually get the answer "I don't know ask Jake" and then Jake says "I don't know ask Jane", Jane then sends you to Bill who may have touched the relevant code at some point. Basically "Collective Ownership" can result in lack of responsibility and messy code that nobody really understands.

I want to take more aim at this "Collective Code Ownership" myth. The concept overlooks the immense amount of job satisfaction one gets from being responsible for a body of code and feeling like you have some responsibility. Handing out responsibility doesn't remove the need for code reviews or bar others from examining and learning different parts of the code. So called "collective ownership" simply gives low-level engineering management more power by keeping developers weak and replaceable but makes for messy code. It makes for messy code because developers don't take a holistic view of what they are doing they just strive to rapidly complete little tasks that are thrown in front of them that management can understand and use to maintain a feeling of control. In short "yes!", it is about you, your growth, and your job satisfaction. I've worked as a consultant in many code shops - when I walk into a shop and the manager introduces Alice "who does our kernel code", and then Bill who "Manages our API code", and Mike "Who is generally responsible for integrations and works on our front end code with Alice" I generally see more happy developers and less turnover.

I also don't believe very much in Pair Programming. Again, all the research I've read supporting the practice is questionable. I've pair programmed at length and watched others do it. Generally it only works for the most trivial of tasks - which means that why use it at all. I do think superiors get a great deal of satisfaction pairing with their subordinates, I'm not so sure about the other way around.

From a software perspective, I would imaging that computers would do a lot more to help validate the intentions of human programmers and that computers will do a lot of the programming themselves.

I would like to see almost all tech powered by renewable sources.

Material science - plastic and other horrible materials should be done away with. I actually think we have gone backwards with respect to materials producing virtually indestructible waste material that poisons our water and air.

"This approach is used within haskell 1 to 1."

He is correct.

I would go further and say the author of the video is just talking about "good programming" in general.

... but if you mentioned any of this at work you would get drummed out of the office with a yellow stripe down your back.

I would still consider the link above editing text... but I posted it anyway for what it is worth.

The idea seems to be to confine the text to its AST in a form like fashion.

It seems that much of the advice centers around chopping up the monolith into services that can be run on a server-less cloud platform.

Uni-kernels, their promise of boot on demand and extremely small footprint, may help with a lot of this. In the very, very, near future devs will be able to package monoliths in ultra light-weight OS's that boot on demand and are optimized for the running application - and do all this on server-less cloud platforms without having to worry all that much.

I'd wager that in 2-3 years many of the use cases of containers will be replaced by Unikernel tech and the desire to run on serverless cloud platforms will be one very big use case.