Programming

Oh boy, here we go (inhales):

**Agile isn't that bad; people just believe they are more productive if they **are "heads down" and not held accountable for what they write/do.

Functional programming isn't that great and doesn't solve all of the world's problems; it just pushes the issues with state to other parts of your design, and doesn't scale well in deeply nested solutions.

IDEs with proper code support (i.e. automatic structure analysis, autocomplete, etc.) are one of the best ways to deal with a large codebase that needs refactoring. Doing widescale refactors without one is asking for trouble. If you believe you don't need it, either your codebase is just that small (which is fine) or playing with fire.

Much of the advice out there on architecture and tooling isn't properly contextualized on the codebase, market, and team situation. If you believe you have the One True Architecture Solution, you are naive. (Ex. Microservices, large complex code pipelines, monorepos, etc.) Be especially wary of anything from FAANG engineering blogs unless you are also in another letter of FAANG.

There. Got it out of my system. Have fun dissecting it.

When writing software that will be deployed to a production environment, it's better to slow down and take the time needed to write a higher quality, more durable solution than to rush and quickly kick a product out the door.

I don't know why this is a hot take, but sometimes it feels like it is.

I really love the project structure of C++. I know ghat it is an archaic design developed like this due to lack of resources, but I find packages extremely offputting.

The first reason is that splitting declaration and implementation across files makes it easier to figure out what something does.

Second reason is that I feel that I have more control over libraries and packages that have to be manuallyaddedto a project rather than using a package manager.

Third, I feel like modern languages iterate over too many versions too fast. C++ has version releases too, but I feel that versioning is handled better from time, compatibility and stability.

If programmers stick to what they know and not try to solve every problem at hand with the latest thing/programming language they've learned then there would be fewer bugs and projects would end by the estimated dates.

I actually like C.

Not everyone can or even should learn programming.

Oop is overrated

I never can understand classes

Python is stupid. Using non printable characters as anything other than token separation is just asking for trouble.

PHP aint all that bad

Carbon? Just what we were all hoping for, yet another programming language from Google. They can keep it.

SQL is the core language that everyone should be required to learn first and foremost.

Shorter code is almost always better.

Should you use a class? Should you use a Factory pattern or some other pattern? Should you reorganize your code? Whichever results in the least code is probably best.

A nice thing about code length is it's objective. We can argue all day about which design pattern makes more sense, but we can agree on which of two implementations is shorter.

It takes a damn good abstraction to beat having shorter code.

Most technology, programming languages and frameworks feel just the same, in a professional environment. Majority of web and apps is so simple that literally anything will do. Simple api consumption, simple database crud stuff. The tech stack doesn't matter that much.

That the entire industry is cyclical and the current trends are yesterday's anarcisms. Oop Vs functional, separating concerns Vs vertical slices, there's examples all over the place.

All of this has happened before and all of this will happen again.

I like C# and Visual Studio

The only thing a GUI text editor can be better at than a terminal editor is making it easier to use the mouse.

I am bad at coding and it is a skill that I do not think everyone can achieve to a professional level, thus telling people to "learn to code" is similar to telling them to "just hustle", "hit the bricks and hand out resumes", and other flippant stories that mean you stop having to think about poverty.

That said, I do believe the narrative actually was true for some people at some time. Maybe in the 90s and early 2000s if you were able to cobble together a computer from bits your university was throwing out and you had internet access, you could punch well above your weight. But that certainly was never true for everyone.

(I like to be optimistic about people's ability to learn things, mostly hampered by access, time, and lack of interest, but I went to a boilermaker's course recently to learn how to weld and none of those kids were going to learn how to code even if they were interested, whatever their other skills were.)

Composition over inheritance has become a meme that people repeat without understanding. Both have their uses, but if composition is all you use, then you're using a hammer on everything. There is no silver bullet in life and most undeniably not in programming.

Also, electron has a reason for existing. If it didn't have a use, it wouldn't have the number of users it has. You can't tell me in all seriousness that Qt, Gtk, Swing, Tkinter is easier to use than electron for the common developer.

Duplicate code can be a code smell, but it's far better to have the same function definition or code block appear twice in the code than extracting a function that tightly couples two components that should not be coupled at all.

See Write Everything Twice (WET) principle.

My hot take: Vi, make and C would have gone the way of COBOL a long time ago if it wasn't for a lot of programmers thinking "my tools are more difficult to use, hence I'm a better programmer".

Designing good UX can be as difficult as writing good code.

Source: Im UI/UX designer and project manager and also QA/QC and also devops and also write the specs and documentation. The only thing I dont do is write the code, DB schema and architecture . The hardest of all those roles is UX. The easiest is project management ("Did anything go tits-up today? No? Well carry on, then ")

Biases: I have no formal training in any of those things and was actually hired as a helpdesk tech.

Abstraction will be the death of traditional software development as we know it

Programming is actually hard af to do for any extended period of time (more than half an hour)

It requires such a specific mind that's drawn to all the detail oriented specific robotic parts of coding but almost all coders say coding is easy because the people whose mind don't fit coding already quit long ago

Yes I find coding hard and no I'm not coping

Actually difficult might not be the word but more like bearable

If you can't find where you missed a closed parentheses, just add a bunch of them to the end of your project like this...

)))))))))

... until your editor's syntax helper tells you it's good. I am very good at coding.

🌶️🥵Many people consume Facebook meta company's tech stack wholesale, don't know how to actually traditionally program their way out of a paper bag, and web dev and devops caused a massive layoff (250k people) at the end of 2022, start of 2023 because it was all vaporware. They consume the same software in droves if the other guy uses it.

There is an entire subculture around it that is just a bunch of medium.com writers, YouTubers and twitter handles just trying to get the clicks for their ad money. Some of these guys have never written valid software or done anything noteworthy. If you meet them head on you'd find they have enormous egos and can't find a counter argument when presented with reason.

I'll even add on that there are many programmers who don't know how to code outside a web app.

Why is something like [react, graphql, react ssr, devops, tailwind, unit tests, containers] vaporware?

• there are other frameworks even with component libraries that are easier to read the code for large codebases, better maintained, and have cohesive full stack solutions, and even faster to develop in, to name one quasarJS or even just plain ecmascript
• if you look at the anatomy of these enterprises using these solutions they've evolved to have micro front ends requiring armies of workers.
• devops is a sales term, the actual implementation of it is so contextual that you'd probably find you don't need a full time job for it half the time and most are relatively easy to setup inside of a business quarter
• not everything is Facebook scale: unless you're padding your resume why did some of these get adopted? How complicated does your app need to be? Did you really need to transpile JavaScript for it?
• unit tests were code to test your code that you're going to have to functionally test anyways: you're telling me that you have to write your code...twice? How the hell did this ever get justified to mangers? Why did the culture not evolve into literal automated smoke tests of the actual builds, instead of testing whether a function that is probably type annotated is going to fire anyways???
• docker/containers suck ass: great that they solved a problem but created a whole new one. we moved to python and JS which were JIT without artifacts and suddenly everything needs a generalized build system to run it. C lang variants and Rust lang compile to a binary you can just run... Ship the small ass binary not an entire container to run your shitty web app

You know the stuff I don't hear about?

• Javascript and Python were steps in the evolution but never the end goal. I'd even say the same of java. There are new solutions but JavaScript in the browser especially should be replaced.
• eye appeal is buy appeal
• that eye appeal shouldn't always mean you need to use a library or framework; vanilla apps work okay too.
• binaries/artifacts/installer packages > containers
• automated testing of the actual end product
• well written logging to the point someone can tell what the application was doing without seeing code
• using all these compsci algorithms to actually write new products and searches from scratch instead of being a framework baby: do you actually need ELK or Splunk for your search? Really?
• you probably don't need MySQL for a lot of projects, I bet you an async library with sqlite would be the same for many of these projects.
• small teams with feature rich apps using SSR, the value of an SSR web app
• the value of a SPA
• the value of traditional desktop software and not using REST APIs

My experience with people from university is that they have extremely strong opinions about things they don't know very much how they work outside theory. There is this syndrome that you have to do everything from scratch with low level languages and keep shitting on anything that uses abstraction to make your life easier.

I don't know why people in this industry have this need of feeling that they're better than others.

GNU make is confusing as hell and shouldn't be used in today's world.

Front end and back end are different enough that you can really specialize in one or the other. They take very different mindsets. I know how to make css obey, I don't know how to make sql performant. Its possible to have both, but not as well.

For every front-end dev, you need 3 back-end guys and a designer.

Programmers are not bad at our jobs, its just not a mature disclipline yet.