Until you know a few very different languages, you don't know what a good language is, so just relax on having opinions about which languages are better. You don't need those opinions. They just get in your way.
Don't even worry about what your first language is. The CS snobs used to say BASIC causes brain damage and that us '80s microcomputer kids were permanently ruined ... but that was wrong. JavaScript is fine, C# is fine ... as long as you don't stop there.
(One of my first programming languages after BASIC was ZZT-OOP, the scripting language for Tim Sweeney's first published game, back when Epic Games was called Potomac Computer Systems. It doesn't have numbers. If you want to count something, you can move objects around on the game board to count it. If ZZT-OOP doesn't cause brain damage, no language will.)
Please don't say the new language you're being asked to learn is "unintuitive". That's just a rude word for "not yet familiar to me". So what if the first language you used required curly braces, and the next one you learn doesn't? So what if type inference means that you don't have to write
inton your ints? You'll get used to it.You learned how to use curly braces, and you'll learn how to use something else too. You're smart. You can cope with indentation rules or significant capitalization or funny punctuation. The idea that some features are "unintuitive" rather than merely temporarily unfamiliar is just getting in your way.
135If you don't add comments, even rudimentary ones, or you don't use a naming convention that accurately describes the variables or the functions, you're a bad programmer. It doesn't matter if you know what it does now, just wait until you need to know what it does in 6 months and you have to stop what you're doing an decipher it.
99Not sure if these are hot takes:
- Difficult to test == poorly designed
- Code review is overrated and often poorly executed, most things should be checked automatically (review should still be done though)
- Which programming language doesn't matter (within reason), while amount of programming languages matters a lot
73Most modern software is way too complex for what it actually does.
67SPAs are mostly garbage, and the internet has been irreparably damaged by lazy devs chasing trends just to building simple sites with overly complicated fe frameworks.
90% of the internet actually should just be rendered server side with a bit of js for interactivity. JQuery was fine at the time, Javascript is better now and Alpinejs is actually awesome. Nowadays, REST w/HTMX and HATEOAS is the most productive, painless and enjoyable web development can get. Minimal dependencies, tiny file sizes, fast and simple.
Unless your web site needs to work offline (it probably doesn't), or it has to manage client state for dozen/hundreds of data points (e.g. Google Maps), you don't need a SPA. If your site only needs to track minimal state, just use a good SSR web framework (Rails, asp.net, Django, whatever).
65The best codebase I have ever seen and collaborated on was also boring as fuck.
- Small, immutable modules.
- Every new features was coded by extension (the 'o' in S.O.L.I.D)
- All dependencies were resolved by injection.
- All the application life cycle was managed by configurable scopes.
- There was absolutely no boiler plate except for the initial injectors.
- All of the tests were brain-dead and took very minimal effort to write. Tests served both as documentation and specification for modules.
- "Refactoring" was as simple as changing a constructor or a configuration file.
- All the input/output of the modules were configurable streams.
There is more to it, but basically, it was a very strict codebase, and it used a lot of opinionated libraries. Not an easy codebase to understand if you're a newbie, but it was absolutely brain dead to maintain and extend on.
Coding actually took very little time of our day, most of it consisted of researching the best tech or what to add next. I think the codebase was objectively strictly better than all other similar software I've seen and worked on. We joked A LOT when it came time to change something in the app pretending it would take weeks and many 8 pointers, then we'd casually make the change while joking about it.
It might sound mythical and bullshity, and it wasn't perfect, it should be said that dependency injection often come in the form of highly opinionated frameworks, but it really felt like what software development should be. It really felt like engineering, boring and predictable, every PO dreams.
That being said, I given up trying to convince people that having life-cycle logic are over the place and fetching dependencies left and right always lead to chaos. Unfortunately I cannot really tell you guys what the software was about because I am not allowed to, but there was a lot of moving parts (hence why we decided to go with this approach). I will also reiterate that it was boring as fuck. If anything, my hot take would be that most programmers are subconsciously lying to themselves, and prefer to code whatever it is they like, instead of what the codebase need, and using whatever tool they like, instead of the tools the project and the team need. Programming like and engineer is not "fun", programming like a cowboy and ignoring the tests is a whole lot of fun.
63You can always solve a problem by adding more layers of abstraction. Good software design isn't to add more layers of abstractions, it's to solve problems with the minimum amount of abstractions necessary while still having maintainable, scalable code.
There are benefits to abstraction but they also have downsides. They can complicate code and make code harder to read.
59Compiler checked typing is strictly superior to dynamic typing. Any criticism of it is either ignorance, only applicable to older languages or a temporarily missing feature from the current languages.
Using dynamic languages is understandable for a lot of language "external" reasons, just that I really feel like there's no good argument for it.
55Go with what works
Error messages should contain the information that caused the error. Your average Microsoft error "error 37253" is worthless to me
Keep functions or methods short. Anything longer than 20 - 50 lines is likely too long
Comment why is happening, not what
PHP is actually a really nice language to work with both for web and command line utils
Don't over engineer, KISS. Keep It Simple Stupid
SOLID is quite okay but sometimes there are solid reasons to break those rules
MVC is a PITA in practice, avoid it when possible
40As an embedded firmware guy for 10ish years:
C can die in a fire. It's "simplicity" hides the emergent complexity by using it as it has nearly no compile time checks for anything and nearly no potential for sensible abstraction. It's like walking on an infinite tight rope in fog while an earth quake is happening.
For completely different reasons: The same is true for C++ but to a far lesser extent.
38Not everything should be beginner friendly. Trying to nerf things because they are not beginner friendly should not be how tools/patterns of languages are designed.
Its ok to have more advanced topic that require more knowledge and that people don't understand from the first moment they see them.
37Shorter 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.
34In unit testing, a "unit" does not have to be the smallest possible section of code. It can be a while class or module or even set of related classes/modules. Testing individual functions in isolation leads to brittle tests that easily break during refactoring. Testing overall system behaviour results in more robust tests that require fewer changes during refactoring which gives you more confidence then you have not introduced a regression.
34The programming languages you use, and the variety of languages you learn, deeply influence how you think about software design.
Software would be much more reliable (in general) if Erlang had become one of the dominant languages for development.
Go sacrifices too much for superficial simplicity; but I would like to see a language that's nearly as easy to learn, but has a better type system and fewer footguns.
Unit testing is often overrated. It is not good for discovering or protecting against most bugs.
Build/test/deploy infrastructure is a genuinely hard problem that needs better tooling, particularly for testability.
32We use too many libraries. This may be an actual unpopular opinion though. I find that the more a library tries to do, and the more dependencies it has itself, the more hesitant I am to use it. It just feels like a tower of cards ready to fall at any moment.
I'm not a very trusting person and work alone though so this might just be an emotional decision. But it is nice having a project be composed of code that does just what is needed and nothing else. It makes it easier to fix bugs and especially to maintain the code.
I do use libraries, but only if they're absolutely necessary or if they're very focused and don't try to do a million things. It's not about size but complexity.
30Web development feels like it's stuck in the early 2000's. I've ranted a lot about it over the years but I just don't know how everyone is okay with it. I'm sure tons of people will disagree.
HTML is bad. The language itself feels unintuitive and is clunky compared to modern markdown languages, and let's be honest, your webpage just consists of nested
<div>tags.CSS is bad. Who knew styling can be so unintuitive and unmanageable? Maybe it made sense 25 years ago, but now it's just terrible. It's very clunkily integrated with HTML too in my opinion. Styling and markdown should be one easier to use language where 50% of it isn't deprecated.
Javascript has been memed to death so I won't even go there. Typescript is OK I suppose.
And now for my hottest take: ~10+ years ago I saw web building tools like Wix and I completely expected web development to head in the direction using a GUI to create, style, and script from one interface, even allowing you to create and see dynamic content instantly. I've seen competitors and waited for "the big one" that's actually free and open source and good enough to be used professionally. It never happened. Web dev has just gone backwards and stuck in its old ways, now it's a bloated mess that takes way more time than it deserves.
The Godot engine is actually a pretty good option for creating GUI apps and it's exactly what I envisioned web dev should've been this past decade. One language, intuitive interface, simple theming and easy rapid development... Shame it never happened.</div>
28Computer hardware has been getting faster and faster for decades at this point, but my computer still slows down. Like WTF. The dumbass programmers take the extra power given to them and squander it instead of optimizing their code. Microsoft word could run pretty well on a windows 98 PC, but the new Word can slow down PCs that are 5-10 years old. Programmers are complete idiots sometimes...
28Oh 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.
27Designing 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.
26MATLAB is an okay programming language when used in the right context. It’s intended for scientific applications, so trying to do your standard object oriented programming with it gets weird. I think we forget that some things were made for a specific purpose- you know, a hammer can’t do everything and all that.
25I really love the project structure of C++. I know that 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 manually added to 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 point of view.
22When 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.
21Carbon? Just what we were all hoping for, yet another programming language from Google. They can keep it.
20TDD is overrated. Code coverage is extremely overrated. Both of these tend to lead to a morass of tests that prove the compiler works at its most basic level while simultaneously generating a surplus of smugness about the whole situation.
Tests have their place. Tests can be, and often are, valuable. But the easier the test is to write, the easier it would've been to just encode it into the type system to begin with.
19I 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.)
18🌶️🥵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
17That 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.
17Composition 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.
16DRY means Do Repeat Yourself, when the alternative is cooking up some awful OOP abstraction
15My 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.
15My mantra has always been to bring solutions not problems. Applying that to code reviews makes for a far more productive experience.
Rather than just pointing out errors in code help the developer with prompts towards the solution.
Or, if you're too lazy to explain why something shouldn't be done then why should another developer have to act on your criticism?
14Write the whole thing, and only then, scrap it and rewrite it. This way you actually have a good understanding of the entire implementation when you are rewriting. When I refractor while writing my draft I will slow myself down and trip over myself, I'll be way more likely to rewrite something I've already rewritten.
Sure there is a limit to the size of projects this can work for, but even for massive projects they can still be broken into decently sized chunks. I'm just advocating for not rewriting function A as soon as you finish function B.
11Programming 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 programming being difficult might not be correct but more like programming is largely unbearable
10Front 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.
10Python, and dynamically typed languages in general, are known as being great for beginners. However, I feel that while they’re fun for beginners, they should only be used if you really know what you’re doing, as the code can get messy real fast without some guard rails in place (static typing being a big one).
9Good programmers need to be creative, flexible (soft skills with others), critical thinkers, and problem solvers. Lacking those kinds of features makes for a rigid and terrible programmer that is near impossible to work with or code behind. Leave the ego at the door.
9My crazy take is that there needs to be a interpretative language alternative to Python which uses brackets to define scope and/or things like elif/else/fi/endif/done. Much easier that way in my opinion, and the ";" shouldn't be necessary. I'm used to Python, but if I had another language which can be used to serve similar purpose to Python with those features, I would never code in Python again when it comes up.
Having to code in Julia and G'MIC (Domain-Specific Interpretative language that is arguably the most flexible for raster graphics content creation and editing), they're the closest to there, but they're more suitable for their respective domain than generic ones.
7Answering my own question here. If you don't have any interest in how the tools you use work, programming isn't "for you" (take that with a grain of salt). If you are writing code and have never looked into how compilers/interpreters work or are using a library and haven't even taken a peak at the library's source code you should because it will make you a better programmer in the long run. And I'm not saying you can't get anything done without that curiosity but curiosity is a major part of being a programmer. Also you don't need to have a deep understanding of the tool just a overview of what it's doing. Like for a compiler understanding what lexers, parsers, ASTs, code generators are will allow you to write code with that in mind.
5Spaces look the same on every screen.
5Types and unit tests are bloat that increase the maintenance cost of whatever code they are involved in. Most types force premature design/optimization. Most unit tests lock up some specific implementation (increasing cost of inevitable refactors) rather than prevent actual bugs.
Nil-punning in clojure has spoiled me rotten, and now every other language is annoyingly verbose and pedantic.
4All programming languages suck, therefore the language you use doesn't matter
3That the HTML/CSS structure of web programming is absolutely disgusting and not necessary. The internet could be and should be so much more from a developer pov. Also people who double space instead of tab often have their mouths open while mashing space 16 times.
I completely understand and clearly see that web development is the future, but I still think it’s all gross and will always prefer targeted efficient compiled code. Why? Because I’m a huge fucking dork.
2Permanently Deleted
1I'm not convinced that "strong pairing" is the best way to pair but even people who rail against agile ideology tell you that you're pairing wrong if you don't follow it precisely.
1If your code files don't contain more lines of comments than lines of actual code, then you're doing it wrong. (For Python, docstrings count as comments)
And your comments shouldn't say what each line of code is doing. If you can code, then you can already tell what each line is doing by just reading the code. The comments should explain WHY it's being done this way, or HOW it's being done, or highlight some pitfalls that might snare a future developer, and generally just give some higher level context to a line or block of code.
1KDE is ridiculously unintuitive and has become too awkward to use to recommend to a newbie.
Arch is not a general purpose distro. Theres too many things that can break it unless you meticulously follow the patch notes and participate in the community.
Vim is overrated.
1Is Haskell, YAML, or Sass also stupid? 🤔
1There are two many programming languages and frameworks. There is a lot of doubling. Why the heck is there Dart/Flutter? Just use Javascript/TypeScript. Why Swift, when you have D, Go, Rust, Python with type annotations, etc.? In my opinion, just too much waste. Of course, in a niche, like OS development or embedded, there can be actually a need for hyper optimized special solutions. But the "mainstream" rest?
0Pure text is probably not the best way to write code, even if it is the most interoperable format
0Strong typing is for weak minds.
You absolutely do not need a computer telling you what types you can put in a collection. Put an assert, write some unit tests, if you aren't sure where data sources come from and can't write a one-line comment.
Dynamic typing makes you fast, it's empowering. Try it and quit being so scared.
-14
