“We’re going to clean up that code later.”
What are some common misconceptions about programming that you'd like to debunk?
Submitted 9 months ago by mac@programming.dev to programming@programming.dev
Comments
0xCAFE@feddit.de 9 months ago
BrianTheeBiscuiteer@lemmy.world 9 months ago
If you’re lucky this statement is actually true 5% of the time.
wesker@lemmy.sdf.org 9 months ago
That you can just go to a bootcamp, and be good at or naturally suited for it.
That you can just go to college and get a degree, and be good at or naturally suited for it.
ShroOmeric@lemmy.world 9 months ago
Well that’s true for every field.
agressivelyPassive@feddit.de 9 months ago
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.
pearsaltchocolatebar@discuss.online 9 months ago
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.
coloredgrayscale@programming.dev 9 months ago
Why are you in programming related communities if you don’t enjoy it?
hightrix@lemmy.world 9 months ago
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.
halloween_spookster@lemmy.world 9 months ago
Myth: software engineers replicate value similar to a factory worker making the same item over and over
Truth: software engineers are closer to artists than factory workers IMO. We find and create new value, not replicate existing value
callouscomic@lemm.ee 9 months ago
And just like artists, the vast majority aren’t very good at it.
Patches@sh.itjust.works 9 months ago
Yes but unlike artists we have far fewer sugar daddies.
porgamrer@programming.dev 9 months ago
eh, more like self-important plumbers
jkrtn@lemmy.ml 9 months ago
Just making some corkscrew pipes because the existing architecture is corkscrew piping.
lambda@programming.dev 9 months ago
I feel this. But, in a lot of jobs you have someone forcing you to do art the way they had envisioned lol
Addv4@kbin.social 9 months ago
That if you know how to code, you understand how computers work and understand really complicated math concepts.
BrianTheeBiscuiteer@lemmy.world 9 months ago
That’s the difference between a programmer and a computer scientist, but even I (a computer scientist) I’m not an expert in hardware, networking, or OS level operations because that’s not my daily focus.
Landless2029@lemmy.world 9 months ago
I compare my career to the medical field. Sure there are some crossovers but lots of specialties.
Would you consult a dentist about your bowel movements?
cole@lemdro.id 8 months ago
and what you just described is the difference between a computer scientist and a computer engineer!
UNWILLING_PARTICIPANT@sh.itjust.works 9 months ago
I don’t even remember my times tables anymore!
lolcatnip@reddthat.com 9 months ago
Oh, that’s easy:
0 1 0 0 0 1 0 1 abbadon420@lemm.ee 9 months ago
I know my wife sets the table at 6 o’clock
jadero@programming.dev 9 months ago
I call that the “nerd equivalency problem”. I think it’s the source of much (most? all?) of the problems with software that comes out of organizations that are not programming shops by nature.
“We’re not moving fast enough (or, “I have this great idea!”), hire another nerd!”
The problem also exists within individual programmers (“sure, I can do that UX/UI thingy, just let me finish building this ray-tracing thingy”), but that’s just an ordinary cognitive weakness that affects us all (thinking that being expert in one field makes one expert in all). It’s the job of proper leadership to resist that, not act as though it’s true.
ICastFist@programming.dev 9 months ago
“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.
Daxtron2@startrek.website 9 months ago
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.
spartanatreyu@programming.dev 9 months ago
1 hour of planning can save 10 hours of work.
1 hour of research can save 10 hours of planning.
okamiueru@lemmy.world 9 months ago
I’m down to 0% the last 6 months. It’s miserable.
tatterdemalion@programming.dev 9 months ago
That a “working” prototype with no tests is just as good as a carefully-designed and well-tested feature. I see this happen so often that a coder puts a prototype in front of a product manager or exec and they are like, “this is exactly what we need, now! Ship that!” And then misery ensues for all of the engineers that need to maintain this piece of garbage. As managers pressure the engineers to build new features on top, they inevitably break fundamental parts of it, and without a confident leader to demand that tech debt is paid off, that product will consume the souls of many desperate coders.
In contrast, if you do it right the first time, there will be significant parts of code that never need to change, and the parts that do need to change will be much easier, because it will be obvious if it breaks the tests.
nilclass@discuss.tchncs.de 9 months ago
That sounds super familiar :D
Anyway, a prototype is not a bad thing, if the managers know the difference. It’s easier said than done to “do it right the first time” if you don’t know how / what to build. Prototypes can be built to validate hypotheses and generally figure out what works, then build the real thing afterwards.
tatterdemalion@programming.dev 9 months ago
Yea I should have clarified. Prototypes are a great idea. The problem occurs when you say, “this is good enough we can improve on it as we go.” Yea good luck balancing priorities when everything breaks from tapping your keyboard too hard.
nitefox@sh.itjust.works [bot] 9 months ago
feature
Please, we ship whole projects without any automated testing whatsoever then we spend month fixing the mess. The company I work for is smort
asyncrosaurus@programming.dev 9 months ago
The company I work for is smort
This is every company I’ve ever worked for. If other people didn’t vouche for their own tests, I’d assume automated testing was a myth.
Strawberry@lemmy.blahaj.zone 9 months ago
hey it’s job security
waz@lemmy.world 9 months ago
I like puting my prototype code in namespaces like “garbage” “trash” “throwaway” etc to emphasize how unfit for production. I’ve no concrete evidence of it’s success, but I like to think it dissuades other team members from using it where they shouldn’t.
firelizzard@programming.dev 8 months ago
As my first job out of college (when I didn’t know what I didn’t know) I was hired to build a bespoke inventory system for a manufacturing company. My prototype became a production system the second I showed it to one of the engineers. The next three months of my life were a living hell as I frantically fixed bugs on a live system. Lesson learned.
pkill@programming.dev 9 months ago
oh yeah and the overt emphasis by suits on frontend development because it feels more tangible. like yeah sure we can add a follow button in a couple lines of code… granted you want to allow duplicate requests by non-signed in users or users that block each other with no manual approvals support and the followee not getting notified
Ephera@lemmy.ml 9 months ago
This one’s a hot take, but: That Python is easy.
I’ve had to work with it in three projects in the past five years and I consider it one of the hardest programming languages, for anything but very short scripts.
You don’t get proper compiler assistance, unless you have 100% test coverage. You don’t get a helpful text editor. You don’t usually get helpful type hints in libraries you use, so you have to genuinely just study the documentation and/or code. You get tons of quirky behavior in the stdlib, build tools, async stack, imports. You get breaking changes in minor versions of the language.
I find writing code in Python extremely mentally taxing, because you just get so little assistance, that you have to think of everything yourself.
agressivelyPassive@feddit.de 9 months ago
Dynamically typed languages all suffer that fate. There’s a reason Typescript literally has that feature in its name.
What does help though is type hinting. You “just” have to enforce it and its fallout in your entire codebase.
Ephera@lemmy.ml 9 months ago
Yeah, we invested a lot of time into type hinting and checking, but mypy would never exit without warnings and errors, because many libraries we were using had no type hints.
It was also just exhausting/cumbersome, having to write type hints everywhere, as there’s no type inference.But yeah, we always joked that someone should create TypeScript for Python – Typhon.
ursakhiin@beehaw.org 9 months ago
I think Python is easy to learn but difficult to get past the basics. I’m also not convinced that getting past the basics is even worth it in three long run. I say this as a person who has used all Python at work for roughly 70 percent of the last 15 years. My current position is moving to Rust and my last 2 positions were moving to Go. Everybody was happier.
lolcatnip@reddthat.com 9 months ago
Yeah, when I was at Google there was a big push among the SREs to switch from Python to Go.
rimu@piefed.social 9 months ago
Try the PyCharm IDE. It's really smart and helpful.
Ephera@lemmy.ml 9 months ago
I’m sorry, but PyCharm is precisely what we were using. I do consider it the best Python editor, but it’s several classes below IntelliJ for Java/Scala/Kotlin or even the extremely new RustRover for, well, Rust. And I’d say roughly at the level of KATE (a non-smart text editor) with just the rust-analyzer language server hooked up.
It is extremely impressive what PyCharm manages to analyze in Python, but other languages offer similarly good tooling out of the box, or make such analysis much easier by having static types.
driving_crooner@lemmy.eco.br 9 months ago
I don’t know if i qualify as a full programmer, I’m an actuarie but 90% of my work is in python, 5% SQL and 5% excel. I love python because is flexible as fuck, I can connect to the SQL server, send the queries to a pd.DataFrame, process the information, scrap some webpage for adicional information needed, and finally export to an excel file that the accounting team can use. I don’t write fully functional programs, but small specific scripts for different tasks. R is another popular programming language between actuaries and statisticians, but I haven’t find anything that R can do, that I can’t in python.
SorteKanin@feddit.dk 9 months ago
I don’t write fully functional programs, but small specific scripts for different tasks.
This is exactly why your experience is different and you like Python better than many others. You are using Python as it was meant to be used and where it excels; for small scripts.
When people say they don’t like Python they mean that Python does a really, really bad job when it comes to larger systems. Static analysis becomes exponentially more important in larger systems and Python has basically 0 of that.
Feathercrown@lemmy.world 9 months ago
I’d say if you program then you’re a programmer. What you’re thinking of is more of a software engineer, ie. someone who architects and creates software.
TehPers@beehaw.org 9 months ago
Might just be my inexperience with the library, but every time I end up with a pandas dataframe, I spend the next 4 hours trying to figure out the right sequence of index statements and function calls to get the data in the order I want. It always ends up feeling like I’m doing something wrong, and the only way to really tell is to run the code as far as I can tell. I don’t use dataframes very often though, and I’m sure it gets easier with experience.
aluminium@lemmy.world 9 months ago
Agree, also just in general I find many things Python very odd and syntactically isolated to some extent. Constructors, lamba, dictionaries in particular are extremly whack.
alsimoneau@lemmy.ca 9 months ago
I’m a scientist that has been coding almost exclusively in Python for the past decade and I strongly disagree.
Python is great at being the glue that holds everything together, and everything crunchy part of the program is being handled by a library anyways.
I code with two terminals, one for iPython and one for vim. And you don’t need anything else. The beauty of Python is that it’s not a language that is so full of boilerplate that you need an IDE to type it for you to be remotely productive.
Overall, Python is a language made to be used by people that need to make something that just works and don’t need to spend years learning programming paradigms and industry practices. Fortran and C are so unwieldy in comparison and everything more modern lacks the expansive and diverse libraries of Python.
SorteKanin@feddit.dk 9 months ago
I’m a scientist
And this is exactly why you like Python. You haven’t had to use it at a truly large scale. See also my comment here: feddit.dk/comment/5769585
Feathercrown@lemmy.world 9 months ago
Overall, Python is a language made to be used by people that need to make something that just works
This is why you find it easy, and why the person you replied to finds is a big pain. The friction other lamguages would give you exists to provide structure on a larger scale that that guy has to deal with. Hence, different languages for different jobs.
driving_crooner@lemmy.eco.br 9 months ago
Thar just because you solved a particular problem in 10min, all other problems are going to take 10min too.
vause@programming.dev 9 months ago
Relevant XKCD: xkcd.com/1425
WalrusByte@lemmy.world 9 months ago
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.
randy@lemmy.ca 9 months ago
And here I was thinking of xkcd.com/664/
BrianTheeBiscuiteer@lemmy.world 9 months ago
I’ve got a lot of these.
Programming is not doing leetcode problems all day long. Those problems can be a good brain exercise or a good prep for a [misguided] technical interview but in a real programming job you have next to no chance of running into problems like those. Even if you do, you’re an idiot if you spend hours toiling away at a problem that somebody else already solved much more efficiently than you will. Your boss doesn’t give a crap if you pulled all of the code straight from your brain.
Programmers are not hackers. The reverse might be true but hacking is about finding problems (and exploiting them) while programming is about fixing problems.
A programmer can do anything that involves code. Maybe not quite this succinct but I think most will assume you can write a mobile app or a website just because you say you can code. Websites, games, apps, and so on are written in code but they all involve different technologies, toolsets, and standards. I’m sure I could fumble my way through any kind of software but don’t expect it done quickly if it’s not my area of expertise.
BatmanAoD@programming.dev 9 months ago
I’m pretty sure that when programmers and other techies call themselves “hackers”, they don’t mean in the security-breaching sense. It means that you can “hack together” something.
agressivelyPassive@feddit.de 9 months ago
Especially regarding the first one: this seems like a very US-centric thing - or maybe a non-german thing. I’ve been in a bunch of interviews on both sides of the table here in Germany and I’ve literally never encountered a single leetcode question. At all.
abhibeckert@lemmy.world 9 months ago
Programmers are not hackers. The reverse might be true but hacking is about finding problems (and exploiting them) while programming is about fixing problems.
You have to find a problem before you can fix it. Programmers are hackers.
Sickday@kbin.run 9 months ago
You don't need to be a hacker to find those problems. You need to be a good detective. All good programmers are detectives.
BrianTheeBiscuiteer@lemmy.world 9 months ago
Programmers have the source code right in front of them, hackers usually don’t. It’s quite amazing what they can do taking shots in the dark.
pkill@programming.dev 9 months ago
tbh the biggest upside of competitive programming sites was when I finally learned some Scala so that I can feel smug about my elegant one-line solutions dabs in a very specific way that makes my arms resemble a lambda /s
BrianTheeBiscuiteer@lemmy.world 8 months ago
Yeah, it has helped me learn about Rust. I mean I still don’t know Rust but it made me realize it’s not for the faint of heart.
cyclohexane@lemmy.ml 9 months ago
Requiring a candidate to know a specific programming language is stupid. Nearly all of the commonly used languages in industry are similar.
It’s maybe more valuable to require knowledge in a specific framework, where knowledge is less transferrable between popular frameworks. Nonetheless, I personally rather hire an engineer that solves problems and learns flexibly rather than one that happens to know the right tech.
AnyOldName3@lemmy.world 8 months ago
I’d say this is pretty dependent on the language. For example, with C++, you need to micromanage (or at least benefit from micromanaging) a lot of things that you can get away without knowing about at all with other languages. That stuff takes time to pick up if you’re self-teaching as you can write stuff that looks like it works without knowing its half as fast as it could be because you aren’t making use of move semantics, and if a colleague is teaching you, then that’s time they’re not spending directly doing their own work. On the other hand, someone with Typescript experience could write pretty decent Javascript from the get-go.
CodeMonkey@programming.dev 8 months ago
C++ is unique in that it is wildly dominant in its niche. I am sure that any developer who has worked with another object oriented, manually memory managed, systems programming language (are there any other popular ones out there?) should have no trouble picking up C++.
onlinepersona@programming.dev 8 months ago
It’s not a black and white issue. “Jack of all trades, master of none” vs “expert of one”. Both have their place and I think it’s better to have a mix than just one or the other.
I’ve seen python newcomers writing code as if they were writing in another language. They don’t know about dataclasses, operator overrides,
__init__vs__new__, metaclasses,__init__.pyvs__main__.py,@property,match, the walrus operator,orassignments, or the common pitfalls of python like mutable defaults, type hints, and a bunch of other things.
Knowing a language in-depth helps write DRY code, avoiding common pitfalls, handling things better like debugging, profiling, and other tooling, and avoiding pitfalls of the language, which newcomers have to first learn, regardless of how their experience with other languages.A lot of stuff is transferable, for sure, but every language uses different idioms, covers different paradigms, and so on. It’s good to have at least one expert on the term to teach others, and to have people flexible enough to switch of willing to learn. Having only experts can mean a static team unwilling to experiment or use better programming languages or technologies. Having only beginners or mediors of a language can produce functional, but sub-optimal code. YMMV
frezik@midwest.social 8 months ago
I used to agree, but now I’m not so sure. There are huge time savings in having someone already familiar with a specific technology. They’ve ran across an issue before and can quickly find the solution.
For example, I started learning Elixir a little over a year ago. I struggled with how to get it to change data in place, and the answer is that you don’t. You work with data in an immutable way; you make a copy with the change made and throw away the original. Once you get used to it, this works very nicely, and Elixir has quickly become one of my favorite languages. However, few other languages force you to work immutably, and nobody does it voluntarily. It takes a bit to get your head around it, and you’ll take a lot longer on any given task until you do.
stevecrox@kbin.run 9 months ago
Technical Leads are not rational beings and lots of software is developed from an emotional stand point.
Engineering is trade offs, every technical decision you make has a pro/con.
What you should do is write out the core requirements/constraints.Then you weigh the choices to select the option that best medts it.
What actually happens is someone really likes X framework, Y programming language or Z methodology and so decides the solution and then looks for reasons to justify it.
Currently the obvious tell is if they pitch Rust.
jplee@lemmy.world 9 months ago
Programming != Computer Science. Programming is just a tool used in computer science. Computer Science is so much more and follows scientific theory and methodology.
nitefox@sh.itjust.works [bot] 9 months ago
That if I can code doesn’t mean I know how to do X thing on your stupid phone
rodbiren@midwest.social 9 months ago
No programming language, development philosophy, or technology can save you from projects and business lacking clarity. Your ability to communicate and be understood is as/perhaps more important than the quality of your ideas. Consistency is better than perfection.
stoly@lemmy.world 9 months ago
Honestly? The people who say “learn to code” as the solution to getting a better job. Only some people can do this.
aluminium@lemmy.world 9 months ago
You NEED to be good be in math to program. Whilest for some highly specialist fields you do for a lot of jobs things don’t get more complex than calculating averages.
CodeBlooded@programming.dev 9 months ago
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…
cyclohexane@lemmy.ml 9 months ago
Some programmers are software engineers. They solve problems, sometimes problems with great ambiguity or non-straightforward solutions.
And some programmers are… code technicians? They understand and write code, but their job seldom involves problem solving. Often times, they’re asked to code an already solved problem, or mostly solved.
This is not a diss. I was in the second camp for a while. But it hurts your career to stay in that. So be careful.
namingthingsiseasy@programming.dev 9 months ago
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.
DmMacniel@feddit.de 9 months ago
Everyone can code.
hawgietonight@lemmy.world 9 months ago
Myth: code can be ugly as long as it works, don’t spend company time on making it look good or on minor optimizations.
The truth is that you can tell when effort has been put into a job. Even if it just works, the lack of discipline means that in the end it will be difficult to maintain and probably will fail in unexpected situations.
Every language has it’s conventions, but if I spot more than a line of separation between blocks of code, that is a common telltale sign of noob. Run from that shit.
vrighter@discuss.tchncs.de 9 months ago
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
saintshenanigans@programming.dev 9 months ago
Gamers demanding changes saying “it’s literally one line of code”
arthur@lemmy.zip 9 months ago
People think computer as magic. That would be nice to make people understand that it’s not. That’s pretty much a dumb machine where we put our intelligence to work.
BmeBenji@lemm.ee 9 months ago
That coding interviews are even by the tiniest measure good indicators of how capable a candidate is for a software engineering job.
space@lemmy.dbzer0.com 9 months ago
When you release something, your work is not done. You have to maintain it, fix bugs, release patches, and probably the worst part, keeping it up to date.
For example, Apple decides to deprecate some API, or decides to switch cpu architecture, or for the millionth time change how app signing works, or add some new security feature that breaks your app. Now you need to make your app work properly on the new platform, switch APIs, all the fun. Or, there’s some critical vulnerability in library you used and customers are deleting your app from their computers (a lot of companies use automated scanners that check against published CVEs). It’s most fun when you learn that the new version that fixes the vulnerability completely breaks compatibility with the old one and now you have to rewrite all the code that used that library.
Also, maintaining open source projects is not fun. It’s a lot of work, in most cases unpaid, thankless, and building a community around a project is really hard.
souperk@reddthat.com 8 months ago
You are not lazy, you probably have ADHD and/or autism. While, accurate numbers are not available, I have seen people estimating that 20% of people working in FAANG are neurodivergent. If coding comes naturally to you but the laundry is your mortal enemy, you should probably educate yourself and see a professional.
ulkesh@beehaw.org 9 months ago
That “just changing a word” is easy and quick. A codebase is an iceberg. Management only really typically understands the surface, but there is a disproportionate amount of ice under the water.
I had to change all instances of a label from a word to an abbreviation. Because we don’t have i18n set up in the app, it ended up affecting 55 different files. I did my best to consolidate into everything calling a common function, but it’s far from perfect. 55 files changed because management said “oh this word here should be shorter”.
PoY@lemmygrad.ml 9 months ago
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
pinchcramp@lemmy.dbzer0.com 9 months ago
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.
agressivelyPassive@feddit.de 9 months ago
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.
pinchcramp@lemmy.dbzer0.com 9 months ago
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?), feeling 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 showed you down and we don’t have time for that. Odd how there was always time for fixing the regressions later.
abbadon420@lemm.ee 9 months ago
I really don’t mind any of it though.
pinchcramp@lemmy.dbzer0.com 9 months ago
Different strokes for folks I guess 🤷♂️