If 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.
Let’s take this one step further. I should be able to get the core ideas in your code by comments and cs 101 level coding (eg basic data structures, loops, and if/then).
Self documenting code is infinitely more valuable than comments because then code spreads with it’s use, whereas the comments stay behind.
I got roasted at my company when I first joined because my naming conventions are a little extra. That lasted for about 2 months before people started to see the difference in legibility as the code started to change.
One of the things I tell my juniors is, “this isn’t the 80s. There isn’t an 80 character line limit. The computer doesn’t benefit from your short variable names. I should be able to read most lines of code as a single non-compound sentence in English with only minor tweaks and the English sentence should be what is happening in most of those lines of code.”
I, too, remember the days before ultra high definition ultra wide monitors.
I thought this argument was bogus in the 90s on a 21" CRT and the argument has gotten even less valid since then. There are so many solutions to these problems that increase productivity for paltry sums of money it’s insane to me that companies don’t immediately purchase these for all developers.
You have a point, devs should be using multiple large monitors. I will often need to have 3-4 files open at once, plus some browser windows. Having some limit on line length helps with this and for fighting code complexity.
I have a massive ultrawide and I still 100% believe in line limits. Long linea are harder to read in general but even with a limit of 100 I frequently have 3 files opened next to each other and I can’t read entire lines easily. Line limits just aren’t about the size of the monitor and I can’t believe people still say that.
This is why code review exists. Writer’s can’t always see what’s wrong with their work, because they have the bias of knowing what was intended. You need a reader to see it with fresh eyes and tell you what parts are confusing.
That’s not to say you shouldn’t try to make it readable in the first place. But reviewing and reading other people’s code is how you get better.
I’m not a professional programmer, I just do mods mostly; C is too common. It was the first language I really used, too. I mean, I learned BASIC first but I didn’t use it for anything outside of learning.
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.
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”.
Yeah, its so much more interesting to edit code with only your keyboard. Always switching back and forth from mouse to keyboard is just too cumbersome.
Bonus points for Neovim: It made me understand my tools (LSP, linting, CLI tools, TUI etc…)
Upvoted for make and c, highly disagree on vi/vim though. It’s significantly nicer not having to use a mouse for 95% of my work. Need to delete between two quotations to replace it? v, i, ", d does it. Whole line? d, d. Beginning of end of document? G or gg. There are keyboards to streamline just about any movement or operation, and none involve the mouse. I still need the mouse for clicking stuff in vs code, but that’s mostly just when committing.
Side shout out to emacs, it’s lost popularity over time, but it can do just about anything
Emacs editor commands are kind of clunky, you hold Ctrl or alt a lot and the movement commands are less intuitive and smooth than vi/vim keyboards imo. I’ve heard it described as: emacs has a text editor, vim is a text editor. Vim is great at editing and moving around in documents, selecting and editing text, and basically anything editor based. Emacs can do notes (org mode, linking notes, searching notes, etc), web browser, file browser, git (better git interface than vim), calendar, agenda, music playing, email… and that’s all without plugins
As a person uses neovim, make and exclusively programs in C I am indeed triggered. Maybe you could argue Make and C are hard but Vi definitely is not (atleast the basics aren’t).
I use the unholy IdeaVim and honestly… I love it. I won’t pretend that interacting with a heavy IDE while using vim is a great idea, but it makes editing so much more comfortable.
Also while you can use something like nano for editing files in the terminal, vi(m) is much faster for more in-depth editing.
As an industry, we like to think of ourselves as supremely rational, but we can’t apply even the most basic scientific principles. So much conventional wisdom has never actually been tested or proven, so we keep reinventing and flip flopping on best practices.
This I agree with, but would excuse it by simply stating investment isn’t there for proper engineering standards. I’d love to produce bug-free tested to reasonably unbreakable, ethically implemented code every single time. But I’d be out of a job pretty quickly and replaced by someone willing to do it faster with more critical bugs and no thought of the ethical implications of a failure.
This one is problematic. JavaScript has many flaws but it’s design of continuing to run through errors is beneficial to front end web development where the developer has no control over the environment.
Although I do believe Javascript is a mess, I’d have to disagree with that. The problem with Javascript and to an extent all client side code is that people uses as a everything tool not neccesarily the language being at fault. People should start to realize handling logic on the backend is perfectly fine and is often better as you don’t need to send several megabytes just to load a simple web page. If we decided to replace Javascript with Python we just recreate the same problem that plagues the modern web.
I don’t mean it doesn’t work for larger projects. Just that it’s a pain to understand other’s code when you have almost no type information, making it, to me, a no go for that
Larger projects in Python (like homeassistant) tend to use type-hints and enforce them through linters. Essentially, these linters (with a well-setup IDE) turn programming in large Python projects into a very similar experience to programming a statically typed language, except that Python does not need to be compiled (and type-checked) to run it. So you can still run it before you have satisfied the linters, you just can’t commit or push or whatever (depending on project setup).
And yes, these linters and the Python type system are obviously not as good as something like a Go or Rust compiler. But then again, Python is a generalist language: it can do everything, but excels at nothing.
Yes, in a good dev workflow mypy errors will not pass basic CI tests to get merged. Types are not really a problem in modern Python workflows, you can basically have a better type checker than Java out of the box (which can be improved with static analysis tools). The biggest problem with Python remains performance.
Go and rust are also generalist languages. Basically all main stream programming languages are and are equally as powerful (in terms of what they can do, rather than performance) as each other as they are all Turing complete. So you can emulate c in python or python in c for instance).
Anything you can do in python you can do in basically any other mainstream language. Python is better at some niches than others just like all other languages are with their own niches - and all can be used generally for anything. Python has a lot of libraries that can make it easier to do a large range of things than a lot of other languages - but really so do quite a few of the popular languages these days.
I mean, it’s still a very nice language. I can see someone, marveled by that, would endeavor to make bigger things with it. I just don’t feel it scales that well.
My own hot take is that I hear this criticism of Python a lot, but have never had anyone actually back it up when I ask for more details. And I will be very surprised to hear that it’s a worse situation than Java/TypeScript’s.
We used to have a Python guy at my work. For a lot of LITTLE ETL stuff he created Python projects. In two projects I’ve had to fix up now, he used different tooling. Both those toolings have failed me (Poetry, Conda). I ended up using our CI/CD pipeline code to run my local stuff, because I could not get those things to work.
For comparison, it took me roughly zero seconds to start working on an old Go project.
Python was built in an era where space was expensive and it was only used for small, universal scripts. In that context, having all packages be “system-wide” made sense. All the virtual env shenanigans won’t ever fix that.
In that context, having all packages be “system-wide” made sense. All the virtual env shenanigans won’t ever fix that.
Sorry, but you’ll need to explain this a little bit more to me. That’s precisely what virtual env shenanigans do - make it so that your environment isn’t referencing the system-wide packages. I can totally see that it’s a problem if your virtual env tooling fails to work as expected and you can’t activate your environment (FWIW, simply old python -m venv venv; source venv/bin/activate has never let me down in ~10 years of professional programming, but I do believe you when you say that Poetry and Conda have broken on you); but assuming that the tools work, the problem you’ve described completely goes away.
The endless packaging solutions for python is exactly the flaw that they’re talking about.
Packaging a python application to work over an air-gap is extremely painful. Half the time its easier to make a docker container or VM just to avoid the endless version mismatch pain.
I don’t think the length of program matters so much, especially with type hints making it easier to maintain larger projects.
That being said, it’s pretty well known in the community that distributing any kind of end user software is a nightmare with python (though there’s a small group of people who insist that it’s not that hard to get people to install python to run their program. Those people are nuts).
The biggest reason I use python for as many projects as is practical, though, is because it has an incredible community that I love to interact with. Unless I truly need something to be scalable, python is always going to be my choice of hammer.
I work at a small organization where code reviews are good, but I’ve noticed that the larger the code review, the faster it needs to get done in order to avoid merge conflicts, which means large code reviews are much less effective in proportion to the size.
I’ve noticed that the larger the code review, the faster it needs to get done in order to avoid merge conflicts, which means large code reviews are much less effective in proportion to the size.
Exactly. And in larger corporations where you have many people contributing and the code is moving fast, having people nitpick your PRs just for show is crap because it delays everything sometimes by days. I had to say no very clearly to some people on code reviews because they were demanding me to place variables in alphabetical order on hard PRs that took quite sometime to get working and were very prone to code conflicts.
Here’s another: most code reviews on larger companies are BS, just for show and nitpicking.
Story time.
Once I worked with a developer that just joined the company straight out of college, and had far more ambition than competency. That developer decided that code reviews where the venue where their high bar for code quality would shine, so they decided to nitpick everything that went against their poorly formed sense of taste. As luck would have it, the developer was assigned to a legacy project that was in cold storage for years and had no tests and linters, and was in a really poor state, and proceeded to leverage that to challenge each and every insignificant detail such as if a space should be at the left or at the right of a symbol. Each code review automatically received dozens of comments nitpicking whitespace changes. What a waste of time with so much noise.
I drop by the project, and noticed the churn that developer alone forced upon everyone, as that team had a rule that all code reviews should be passed by all reviewers and that reviewer made it their point to reject reviews that didn’t complied to their opinion on whitespace. So the first thing I did was onboard a code formatter, and made it my point to subject the spec to an unanimous code review. That problematic developer made it their point to nitpick away each and every single setting, but it turned out some of their opinions conflicted with previous feedback.
So the code formatter tool was onboarded onto the team. Did that stopped the problematic developer from continuing their nitpicking? No. Except this time around other developers started pushing back because the opinions were contradictory and contrasted with the official code formatting style.
All it took was a couple of days for the problematic developer to go from dozens of comments per day to zero. The code formatter was still optional and not fully adopted, but the problematic developer simply ceased with the bickering.
I wish this had been my experience. I pushed for so long in my last company for standards to be written, code formatters implemented and objectivity to be brought to reviews but it was always ignored.
Instead I had to endure every employee who claimed seniority (in a non hierarchical company) subjecting their opinion on style in reviews. It came up the point that I dreaded having to work with specific people because they kept triggering my PTSD with their moving target of micro management.
Only afterwards did I truly appreciate how poor a lot of their opinions were. Now one of my first questions when approaching a new project is what standards we’re following. If they look at me blank faced that’s a pretty solid red flag.
Everybody trashing on code reviews has never worked with a shit coder before
I’m a shit coder and almost every single review I’ve made big mistakes like forgetting to delete debug/dead code and there’s always meaningful improvements being suggested
This was my experience too. At first I found code reviews to be an invaluable resource for improving my code. But I then reached a point where I’d learned everything I could from a particular reviewer.
I’d submit code that met every criteria, but the reviewer would still nit pick on tiny details that were entirely subjectective. It was no longer about the quality of code it became about the reviewer trying to put their mark on my work.
The only solution was to either ignore their nits or adopt the hairy arm technique whereby you include intentional errors for the reviewer to comment on so they feel their time had been valuable and you get away without yours being wasted.
I worked with a guy who brought 10k lines of code from various jobs over the years and slapped it all into a single commit second day on the job.
It was all VB.NET and looked like it was written in VB6 days because it was reimplementing functions that the .NET framework already provided us. And there were quite a few single line functions that did the simplest things like addition of two variables.
However my favorite function of all was IsMarksMachine() because it was used as a prod/dev switch. I ran into bugs testing the code and got the “Worked on my machine” line. Turned out the code branch under IsMarksMachine() somehow worked, but in all other cases, it didn’t.
Mark is not the real name. But man was he a bad coder.
That doesn’t mean you are a shit coder, you are just likely forgetful. I also find stupid shit in my committed code, though that is also due to me not caring too much (I guess I really have burned out at my previous work place).
Now I’m at a better job, hopefully I can take proper care of my work here! Hopefully you don’t suffer from burnout.
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 programming being difficult might not be correct but more like programming is largely unbearable
Stick with it. Programming takes a long time to learn - and I don’t mean the fundamentals; I mean there’s so much to the job that just takes experience to pick up.
After a while, you can pick up a problem/feature, dive into a code base and instead of becoming lost, things just slide into place in your brain and you can focus on the problem/feature rather than having a whole bunch of non essential stuff stuck in your head.
And the secret to getting there is simply wanting to understand. Don’t be satisfied with knowing that you fixed a problem, make sure you understand why your fix worked. Don’t sweat the bigger picture, just focus on each task. And get good at debugging early, that helps soooo much.
The people who say coding is easy do it because it does become easy eventually and then eventually you forget how hard it was in the beginning. It’s also a lot easier if you find it fun and can practice in an environment where you don’t have crazy deadlines to meet and have a good teacher or mentor who is willing to help along the way.
All conventional wisdom and many teachers of mine have told me I should be brilliant at programming cause I’m smart, good at math, good with computers etc.
But I’m sloppy with details and can’t think robotically.
We spend too much time focusing on the wrong skills in coding
Web 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>
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.
Yet Markdown languages are far, far more limited in both scope and functionality than HTML is. How do you bridge this gap without making it just as complex?
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.
They didn’t start by writing a spec with half of it deprecated already. They started with something, and over time kept developing it - and deprecating other parts. No matter what you propose, unless it’s 100% absolutely perfect (and nothing ever is) you’ll end up in the same situation. The only other choice would be to break backwards compatibility, which is obviously not a good thing to do.
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.
People say the same about no-code frameworks. There’s a good reason that stuff doesn’t work beyond the absolute basics. If it was really possible, HTML+CSS+JS give you all the necessary tools to build it. You won’t get there with a more limited system.</div>
The only other choice would be to break backwards compatibility, which is obviously not a good thing to do.
There are other options. A version on html/css/js would be good IMO. Then you can remove things you should not use in newer versions or make other breaking changes and better evolve the standard. Yes the browsers need to implement and understand each version. Much like how rust works with its editions.
This increases complexity a lot, since you don’t just have to implement compatibility with the editions etc., but also have to properly test a giant amount of cases against all of them. What is the advantage compared to marking things as deprecated?
Yet Markdown languages are far, far more limited in both scope and functionality than HTML is. How do you bridge this gap without making it just as complex?
That’s a really big topic but in general I’d combine theming and markup to one language (not necessarily coupling CSS and HTML in one file but having something that does both with similar syntax and rules), make things simpler so there’s one clear way of doing something rather than using a generic container for everything, etc.
No matter what you propose, unless it’s 100% absolutely perfect (and nothing ever is) you’ll end up in the same situation.
Obviously deprecating a few things will happen over time but the reason web dev is how it is now is because technology used to be a lot more limited and websites were a lot simpler. 25 years ago, nobody knew what the “modern web” would look like. We know what specifications we would need now if anybody went back and re-did them, I think you’d end up with something better.
People say the same about no-code frameworks. There’s a good reason that stuff doesn’t work beyond the absolute basics.
I don’t think they’re comparable. You won’t use a GUI and drag-and-drop for everything obviously, you’d still be able to add sections with code.
The fact that Wordpress powers almost half the internet is proof that a simpler web dev experience like this is in demand and it can work. Most websites don’t need something complex, just something that supports rapid development and is intuitive, and doesn’t make it easy to fall into bad practices.
That’s a really big topic but in general I’d combine theming and markup to one language (not necessarily coupling CSS and HTML in one file but having something that does both with similar syntax and rules), make things simpler so there’s one clear way of doing something rather than using a generic container for everything, etc.
You’d have to show an example of such a language, it’s difficult for me to imagine a good combination between styles and markup - it’s good that they are as separate as they are, intertwining them makes the web less useful.
Obviously deprecating a few things will happen over time but the reason web dev is how it is now is because technology used to be a lot more limited and websites were a lot simpler. 25 years ago, nobody knew what the “modern web” would look like so it was made up as people went along. We know what specifications we would need now if anybody went back and re-did them, I think you’d end up with something better.
We know the specifications we need for current development and applications. If we were to “reset” and build new specifications now, how do you know they won’t be just as useless in 25 years?
I don’t think they’re comparable. You won’t use a GUI and drag-and-drop for everything obviously, you’d still be able to add sections with code. The fact that Wordpress powers almost half the internet is proof that a simpler web dev experience like this is in demand and it can work. Most websites don’t need something complex, just something that supports rapid development and is intuitive, and doesn’t make it easy to fall into bad practices. Like I said, it’s a hot take, but I would prefer it so much this way.
Well, isn’t WordPress then what you’re asking for?
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.
My websites do not consist of nested divs. Your webpages might just consist of nested divs, but only if you are clueless about what you’re doing and are oblivious to basic stuff like accessibility support.
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.
Being unmanageable is the output of the developer team, not the languages they use. Decoupling Presentation from the data and semantics never ceases to make sense. CSS has many issues but the way its integrated with HTML is certainly not one of them.
Frankly, you sound like you blame your tools a lot.</div>
I think that Godot GUIs are very limited compared to HTML+CSS. It’s not a huge problem for videogames since screens sizes aren’t going to vary as much as for a web app. But it would never work well for proper responsiveness on different screens.
It’s definitely not perfect (and definitely not a replacement for web apps) but I think it’s a big step in the right direction for GUI development. People have made impressive apps with it.
Nope, my webpages are not just nested divs. I use nav, main, form, select, etc to name a few. I actually use very few JS. It’s mainly for communication with the server when I need AJAX to retrieve data.
You 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.
Having fun when programming should be much more important than having correct or fast code when you’re a programmer and should be what we should aim for first.
Having fun when programming should be much more important than having correct or fast code (…)
That’s only remotely reasonable if you’re a weekend warrior that messes with coding as a pastime. Even so, I’m not sure what fun you can extract from dealing with slow, broken code.
Of course those concepts are intertwined in some way.
But as a full time lead dev of a relatively big project, I find that a lot of people, often junior devs, concentrate a lot on what they think is “good code” and not a lot on whether they and other devs are having fun. It may make sense when you’re junior and you have to learn a lot at once, but when you’re experienced enough I feel that focusing on having fun, both for you and your team, should be much more important to us than focusing on precepts you read on having fast code and theoretically clean code, as long as it doesn’t lead the code to be less fun to work with in the long run.
For example, doing R&D re-implementing things from scratch, in most cases just to throw away the great majority of it, could be considered as fun by most programmers, even when it makes not much sense because what you did before also worked. As with switching some architecture around (perhaps wrongly, but it’s hard to know sometimes before you tried it).
I’ve come to very much dislike scrum or agile management as well due to all its protocols and the ways it enforces a certain way of progressing (with tickets, progress reporting, mostly short-term work) which focuses on the project’s goal (which really is what the company wants), sometimes at the expense of devs experimenting and just having fun (what I advocate we should aim for). Though it all depends on your project and company I guess.
It can be rewarding. For me, this has a lot to do with team culture. Am I supported and given the time needed to make improvements as I go or am I constantly rushing to make a deadline?
So much. When I’m trusted to find the right balance of productivity and quality, I enjoy the work more. When I enjoy the work, I’m more productive and write better code. It’s a positive feedback loop.
I forgot where I heard this, but at one point around the same time, Microsoft was trying to get BASIC embedded into webpages for Internet Explorer as a competitor to JavaScript.
What do you mean going to? Internet Explorer supported VBscript, which was a “competitor” to Javascript. Though being locked to ie was a hindrance to adoption. That, and it was based on vb.
The JavaScript ecosystem is made worse by the legions of “developers” in it which amount to bro-velopers that put no thought into if something is needed before they create it. There’s a strong overlap between the idiots in crypto and JavaScript developers that needs to be decoupled drastically.
Add comment