The misconception that we’re the person to go to to fix your printer…
…I mean we probably can fix it, but it’s a waste of our time…
10% of my ability to fix your computer is because I know the issue
90% is that I don’t panic at error messages and I know how to use a search engine
That you can just go to a bootcamp, and be good at or naturally suited for it.
That you can go to college and get a degree, and be good at or naturally suited for it.
Well that’s true for every field.
But programming is definitely more open to the idea of people just showing up and claiming to know stuff. You wouldn’t trust Steve to build a bridge just because he watched a bunch of engineering videos on YouTube.
Eh, I’m naturally good at it. I got shoved into the programming UIL group in school with absolutely no background in programming and tied for 3rd place.
But, I really don’t enjoy doing it.
Exact same thing happened to me. Group project needed a programmer, I was a gamer with a nice computer so I volunteered. 15 years later and I’m a software engineer at a huge company.
Why are you in programming related communities if you don’t enjoy it?
I browse by all
Plus, I have to do light coding for my job (script writing)
Everyone can code.
Anyone can, but not everyone needs to
And not everyone should.
I didn’t want to say that because it sounds mean, but yes, pretty much
Not everyone should
Thar just because you solved a particular problem in 10min, all other problems are going to take 10min too.
Relevant XKCD: https://xkcd.com/1425
What’s funny about this comic now is the second one has become very attainable in the years since it was released. The concept still applies though. Some things are a lot harder than they seem on the surface.
Somebody spent the money on a research team and five years is why it is very attainable now.
Someone trying to write the code from scratch would still take a research team and years to replicate it from scratch.
Oh yeah, for sure
And here I was thinking of https://xkcd.com/664/
It is fun
That’s subjective. I find coding fun.
Both of your comments hurt in that way only the truth is capable of hurting.
i didn’t want to flood the thread - there’s more where that came from
That programming as a career means you’re going to spend writing nice, clean code 80% of the time.
It’s rather debugging code or tooling problems 50% of the time, talking to other people (whether necessary or not) about 35% of the time and the rest may be spent on actually spending time doing the thing you actually enjoy.
I may be exaggerating, but only a little.
I really don’t mind any of it though.
Different strokes for folks I guess 🤷♂️
In my experience, you’re rather inaggerating. I’m not even 10y into my career and if I get to actually code for 2h a day, that’s already a success. Most of my time nowadays is documentation, meetings, jira, research and calls with the clients.
I think it heavily depends on the size and (management) culture of your employer. My most recent gig had me sit in way too many meetings that were way too long (1hr daily anyone?), dealing with a lot of tooling issues and touching legacy code as little as possible while still adding new features to our main product on a daily basis. Obviously “we don’t need a clean solution. We’re going to replace that codebase anyways, next year™”.
The job before that had me actually code for about 80% of the time, but writing tests is annoying and slows you down and we don’t have time for that. Odd how there was always time for fixing the regressions later.
also microservices in my experience worsen this sort of bitrot where the amount of usual duplication it involves means that even if you manage not to have poorly documented spaghetti magic that gets updated once in an eon in one service or two it still might be elsewhere and this
- discourages refactoring due to the duplication
- harms consistency
- encourages lousiness because your stuff might mostly work on a surface level with the rest of your system because you only expose APIs and don’t need to worry that much about how your methods will be called. Which might seem convenient to use and implement in an ideal scenario, but could easily become troublesome to debug if anything goes wrong.
I think it’s also a question of how you position yourself. Without noticing it, I’ve developed a kind of “will to power” in the sense that I want to shape the product we’re working on. So instead of just sitting in my corner and working on ticket after ticket, I’m actively seeking conversations with stakeholders to find out, whether it even makes sense to implement it as described in the ticket, or propose new ideas, etc.
Also, my mother taught me (by virtue of being completely untechnical) how to explain complex problems and systems in a way that non-technical people understand. So if “a developer” was needed, management often enough volunteered me.
I could pull myself mostly out of this stuff, but I’d get even more frustrated not being able to at least try to make things a bit better. So I’m putting on the headset once more.
It is cool
“Programming is just writing code”
Programming is, first and foremost, understanding what the fuck you want/need the computer to do. That means that some programmers (mostly analysts) may understand workflows and processes better than the people whose job depends on their knowledge of said things.
People don’t realize that as you get better at programming, the amount of code you write goes down. At least in my experience, my work day has shifted to 80% thinking about what I’m going to write and then about 20% actually writing it.
I’m down to 0% the last 6 months. It’s miserable.
Time for a job switch
It was the job switch that landed me in that situation. A change from a small company where about 70% was actual productivity, to a large corporation, in a team where there was severe issues with planning and working on the correct problems. So far it’s been 6 months of… well, wondering if I’m missing something, or a bigger picture somewhere, to trying to turn the ship in the right direction. If it’s still like this in another 6 months, I’ll consider a change of scenery.
That’s fair, that definitely can happen with a switch. My first year at my current company was like that and occasionally still is lol. Luckily our next few quarters I’ll be on a team that has much nicer processes so I won’t be twiddling my thumbs waiting for solid requirements.
waiting for solid requirements
This is exactly the situation. Except that my team consisting of consultants just “started”, instead of trying to scope out the constraints and larger picture. I joined a month or so after.
Six months, and the result so far of their exploration is a fairly uninteresting happy-path use of some technologies, barely related to the task that had unclear requirements. Turns out the work done is unsuited for it. Boggles the mind how much resources are wasted on such things.
Feels extremely unrewarding to have worked, relatively hard, for half a year, and the fruits of my labour is… getting to the point where the actual problems are solved. Which one could have done from day one, if one had started in a team without wrong preconceptions, or, no team, for that matter.
Yeah I would not like that situation at all. I was very adamant about not starting our latest project until we had firm requirements. Of course that didn’t happen but I was very careful about designing in a way to be flexible enough to change to requirements. Had a major change halfway through but only lost a week or two which could’ve been much worse.
1 hour of planning can save 10 hours of work.
1 hour of research can save 10 hours of planning.
This one might be a bit controversial, but has rung true in my general experience. Probably a lot of exceptions to these rules, but here goes:
You don’t really know a programming language until you understand a fair amount of the standard library and how packages/modules/dependencies work. Syntax is pretty easy, and any mainstream language will work just fine for solving basic leet-code style problems. But when you really spend a lot of time working with a language, you’re going to spend more time learning about common libraries and how to manage dependencies. If you’re working with a language like C++ or Java, this could also include build systems and how to use them.
Another precursor to being able to say that you know a language is that you should also be familiar with best practices (ie. how to name modules, how to write documentation, etc.) and common pitfalls (undefined behavior, etc.). This is one of the hardest parts about learning a new language in my opinion, because the language may not necessarily enforce these things, but doing them the wrong way can make your life very difficult.
Counterpoint: knowing a programming language doesn’t matter if you can solve problems. A competent programmer can pick up a new language and be productive within a few months. That is, a new language within the same paradigm - going from a imperative language to a functional language can be a drastic shift, but going from one imperative language to another is easy. If you can’t do that as a intermediate to senior developer, you’re not a competent programmer IMO.
The real skills of a good programmer are things like problem solving, debugging, understanding how to write readable and maintainable code, etc. Having deep knowledge of a specific programming language or languages is helpful and enables you to work faster, but if you’re only a skilled developer in the languages you know - if you aren’t capable of pivoting those skills to another language - you aren’t a skilled developer IMO.
Agreed overall, you will still be competent switching from one language to another, but intricacies and nuance matter a lot here. You may have enough knowledge to solve problems, but will you have enough knowledge to avoid creating new ones too? Like performance issues, or memory leaks, or other unwanted behavior? C++ is a great example here: someone that’s smart but inexperienced might just be dangerous enough to start writing classes with dumb pointers without overriding the copy constructors, and this is just a recipe for disaster.
I think it would take more than a few months to develop the kinds of experience that you need to be aware of these issues and avoid them. And while C++ is a very easy example to point out here, pretty much all languages have their share of footguns to be aware of, and it just takes time to learn them. A “deep knowledge” of a language is not just about being faster and more productive; it’s also about not creating more issues than the ones your solving.
That’s what I hate about javascript, it doesn’t warm you about undefined behavior, it just throws.
I used to not really care about that, but after learning C and Rust, damm, I wish there where result types everywhere
Some small nits to fix:
-
C has it’s own undefined behavior.
-
JS has confusing behavior, not undefined behavior. Its specs are well defined and backwards compatible to a fault, making some things unintuitive and harder to learn if you don’t learn the history of the language.
-
Problems with both should be avoided by learning and using standard practices. (Don’t pretend C is object oriented, always use
===instead of==in js, etc…)
In complete agreement:
- Result types are awesome, all future languages should be designed around them.
thank you very much.
By undefined I meant the usage of undefined in the language, however you phrased it way better :)
-
There are no absolutes, and most of these “myths” are at least true to some extent. Much like any paradigm (worse is better, whitebox testing, lbyl vs eafp, etc), none are universally best. And all are helpful to know about.
less about programming, more about programmers: just because you can code an app doesn’t mean you know jack shit about anything else… politics included
so many software engineers think they’re the only one who understands the world and that they are the one to have the final say in any discussion
i think that stems from their outrageous overpayment
He’s getting downvoted but he’s right.
The hubris of a dev thinking they can solve a non tech problem with tech that they know nothing about, it’s almost unmatched.
Maybe he’s getting downvoted for his US defaultism.
This also works the other way round:
The best programmers won’t be able to fix you clunky mess of bureaucracy by making it digital.
That Python is the most readable language. Merely forcing an indentation style is only part of the issue. Python programmers have a tendency to write a bunch of named parameters all on one line, and it’s a mess.
Even the automated documentation can’t make it right. What the hell is this shit?
class werkzeug.test.EnvironBuilder(path='/', base_url=None, query_string=None, method='GET', input_stream=None, content_type=None, content_length=None, errors_stream=None, multithread=False, multiprocess=False, run_once=False, headers=None, data=None, environ_base=None, environ_overrides=None, mimetype=None, json=None, auth=None)This is not enlightening. It might as well go on the shelf next to the worst regex you’ve ever seen. The automated doc generator needs to break these up to put one arg on each line, or just omit it altogether and let the detailed docs handle it.
It’s not just the doc generator, either. I see this kind of style all the time in Python code. It’s unreadable and it also makes it harder to figure out diffs when a parameter in the middle is changed (though it’s helped by color coding for pull requests on GitHub and the like).
It’s almost like the language attracted a bunch of people who thought indentation was the only thing you needed to make readable code. No further thought put into it.
I don’t disagree that this is hard to read, but I feel it’s worth mentioning python has a pretty acceptable style guide. The problem is, it’s far less common in python to bundle parameters into some holding object. So here you have massive function that has to accept a lot all at once. In use it’s probably not as bad looking however.
And at least, it actually explains all the damn parameters. It’s a lot nicer than seeing functions parameters you don’t understand, and all you have is the name. This is not limited to python either
There are plenty of other languages that have named parameters but no holding object. You format it like this:
some_func( foo: 1, bar: 2, baz: 3, )And this works fine. Of course, not everyone does that, but I almost never see it done in Python.
This style comes into conflict with rules that functions shouldn’t be longer than 20 lines for whatever. The solution to that is to be relaxed about the line count rule. I’d rather see 40 trivial lines than 20 with everything crammed up.
You NEED to be good be in math to program.
Whilest for some highly specialist fields you definitly do, but for a lot of jobs things don’t get more complex than calculating averages.
I’d argue that you do need to be good at math to be an effective programmer, it’s just that that doesn’t mean what a lot of people think it means. You don’t need to know all the ins and outs of quadratics, integrals, and advanced trigonometry, but I think you do need to have a really solid, gut-level understanding of basic algebra and a bit of set theory. If you’re the sort of person whose head starts to swim when you see “y=3x+2”, you’re going to find programming difficult at best.
I don’t even know what a y=3x+2 is but I have no problem with programming, algorithms and data structures
I don’t think it’s so much about the actual math, but learning good logic and problem solving skills, which math helps with.
OTOH, you need to be good at the same kinds of reasoning that leads one to be good at math. Not knowing much math isn’t a problem, but not being able to learn math is probably a dealbreaker.
Nail on the head.
The reason programming curriculums are so math heavy is because of teaching logic.
You’re either right or wrong in math. There is ONE answer to the formula. You can sometimes get there different ways though. The logic on your path is the key.
I’d I unironically say that philosophy and logic classes are extremely helpful for programming.
When I was in college I took a symbolic logic class taught by the philosophy department that was indeed useful. OTOH, I was told later it was originally created as a CS class and only moved to the philosophy department for political reasons.
I’m bad at math and struggled heavily through calc 2 and barely passed with a D+ but had little issue with data structures and algorithms (except when the algorithms were written in math notation, but still got through it after being explained in a logical set of steps instead).
Gamers demanding changes saying “it’s literally one line of code”
yeah maybe would be true if FP/FRP was widespread in gamedev… but then the industry would be moving at significantly slower pace ¯\(ツ)/¯
that doing more work, takes more time.
Gamers are especially guilty of this.
"that 2013 game runs at a smooth 60 fps. This medern game running at quadruple the resolution with raytracing sometimes dips to 58 fps on the same hardware. Devs must be lazy, they just need to add OPTIMIZATION to the game
I don’t know what it’s called, but it’s a common phenomenon: available room will be exploited. It’s exactly why computers nowadays don’t feel faster than computers from a decade or two ago: they do so much more because they can.
Stuff like electron would’ve been impossible in 2000 or 2005: it’s just a behemoth in terms of computational needs and power consumption. Earlier computers would’ve struggled endlessly with it. Current hardware however makes it seem as fast as previous tech.
