Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
![](/static/devrant/img/pipeless-devrant-banner-white.png)
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
Search - "bug-free code"
-
When you finally accept that the code will never be bug-free and instead make friends with the uncaught exceptions.1
-
1 - Programmer produces code he believes is bug-free.
2 - Product is tested. 20 bugs are found.
3- Programmer fixes 10 of the bugs and explains to the testing department that the other 10 aren’t really bugs.
4 - Testing department finds that five of the fixes didn’t work and discovers 15 new bugs.
5 - Due to marketing pressure and an extremely premature product announcement based on overly-optimistic programming schedule, the product is released.
6 - Users find 137 new bugs.
7 - Newly-assembled programming team fixes almost all of the 137 bugs, but introduce 456 new ones.
8 - Entire testing department gets fired.
9 - Company is bought in a hostile takeover by competitor using profits from their latest release, which had 783 bugs.
10 - New CEO is brought in by board of directors. He raises the programming team's salary to redo the program from scratch.
11 - Programmer produces code he believes is bug-free.
12 - fml9 -
Aparently there is piece of code out there, which is completely bug free.. its called hello world.8
-
At one of my former jobs, I had a four-day-week. I remember once being called on my free Friday by an agitated colleague of mine arguing that I crashed the entire application on the staging environment and I shall fix it that very day.
I refused. It was my free day after all and I had made plans. Yet I told him: OK, I take a look at it in Sunday and see what all the fuzz is all about. Because I honestly could fathom what big issue I could have caused.
On that Sunday, I realized that the feature I implemented worked as expected. And it took me two minutes to realize the problem: It was a minor thing, as it so often is: If the user was not logged in, instead of a user object, null got passed somewhere and boom -- 500 error screen. Some older feature broke due to some of my changes and I never noticed it as while I was developing I was always in a logged in state and I never bothered to test that feature as I assumed it working. Only my boss was not logged in when testing on the stage environment, and so he ran into it.
So what really pushed my buttons was:
It was not a bug. It was a regression.
Why is that distinction important?
My boss tried to guilt me into admitting that I did not deliver quality software. Yet he was the one explicitly forbidding me to write tests for that software. Well, this is what you get then! You pay in the long run by strange bugs, hotfixes, and annoyed developers. I salute you! :/
Yet I did not fix the bug right away. I could have. It would have just taken me just another two minutes again. Yet for once, instead of doing it quickly, I did it right: I, albeit unfamiliar with writing tests, searched for a way to write a test for that case. It came not easy for me as I was not accustomed to writing tests, and the solution I came up with a functional test not that ideal, as it required certain content to be in the database. But in the end, it worked good enough: I had a failing test. And then I made it pass again. That made the whole ordeal worthwhile to me. (Also the realization that that very Sunday, alone in that office, was one of the most productive since a long while really made me reflect my job choice.)
At the following Monday I just entered the office for the stand-up to declare that I fixed the regression and that I won't take responsibility for that crash on the staging environment. If you don't let me write test, don't expect me to test the entire application again and again. I don't want to ensure that the existing software doesn't break. That's what tests are for. Don't try to blame me for not having tests on critical infrastructure. And that's all I did on Monday. I have a policy to not do long hours, and when I do due to an "emergency", I will get my free time back another day. And so I went home that Monday right after the stand-up.
Do I even need to spell it out that I made a requirement for my next job to have a culture that requires testing? I did, and never looked back and I grew a lot as a developer.
I have familiarized myself with both the wonderful world of unit and acceptance testing. And deploying suddenly becomes cheap and easy. Sure, there sometimes are problems. But almost always they are related to infrastructure and not the underlying code base. (And yeah, sometimes you have randomly failing tests, but that's for another rant.)9 -
Here's a true story about a "fight" between me and my project manager...
I've been working as a Frontend developer for nearly two years, managed to acquire a decent amount of knowledge, in some cases well above the rest of my coworkers, and one day I got into a bit of a disagreement with my project manager.
Basically he wanted me to copy/paste some feature from another project (needless to say, that... "thing" has more bugs than an ant farm), and against his orders I started doing that feature from scratch, to build a solid foundation from the very start.
I had a lengthy deadline to deliver that feature, they were expecting me to take some time to fix some of the bugs as well, but my idea was to make it bug-free from the moment the feature was released. Both my method and the one I should be copying worked the exact same, but mine was superior in every way, had no bugs, was scalable and upgradeable with little effort, there was no reason not to accept it.
We use scrum as our work methodology, so we have daily meetings. In one of those, the project manager asked me how was the progress on that new feature, and I told him I was just polishing up the code and integrating it with the rest of the project, to make sure everything was working properly. I still had a full day left before the deadline set for that feature, and I was expecting to take about half an hour to finish up a couple lines of code and test everything, no issues so far...
But then he exploded, and demanded to know why wasn't I copying the code from the other project, to which I answered "because this way things will work better".
Right after he said that the feature was working on the other project, copying and pasting it should take a few minutes to do and maybe a couple of extra hours to fix any issues that might have appeared...
The problem here is, the other project was made by trainees, I honestly can't navigate through 3 pages without bumping into an average of 2 errors per page, I was placed into this new project because they know I do quality code, and they wanted this project to be properly made, unlike the previous one, so I was baffled when he said that he preferred me to copy code instead of doing "good" code...
My next reply was "just because something has been made and is working that doesn't mean that it has been properly made nor will work as it should, I could save a few hours copying code (except I wouldn't save any, it would take me more time to adapt the code than to do it from scratch) but then I'll be wasting weeks of work because of new bugs that will be reported over time, because trust me, they will appear... "
I told him this in a very calm manner, but everybody in the meeting room paused and started staring at me, not many dare challenge that specific project manager, and I had just done that...
After a few seconds of silence the PM finally said... "look, if you manage to finish your task inside the set deadline I'll forget we ever had this conversation, but I'll leave a note on my book, just in case..."
I finished that task in about 30 mins, as expected, still had 7 hours till deadline, and I completely forgot about that feature until now because it has never given any issues whatsoever, and is now being used for other projects as well.
It was one of my proudest/rage inducing moments in this project, and honestly, I think I have hit my PM with a very big white glove because some weeks after this event the CEO himself came to the whole team to congratulate us on the outstanding work being made so far, in a project that acted against the PM's orders 90% of the time.11 -
Okay, story time.
Back during 2016, I decided to do a little experiment to test the viability of multithreading in a JavaScript server stack, and I'm not talking about the Node.js way of queuing I/O on background threads, or about WebWorkers that box and convert your arguments to JSON and back during a simple call across two JS contexts.
I'm talking about JavaScript code running concurrently on all cores. I'm talking about replacing the god-awful single-threaded event loop of ECMAScript – the biggest bottleneck in software history – with an honest-to-god, lock-free thread-pool scheduler that executes JS code in parallel, on all cores.
I'm talking about concurrent access to shared mutable state – a big, rightfully-hated mess when done badly – in JavaScript.
This rant is about the many mistakes I made at the time, specifically the biggest – but not the first – of which: publishing some preliminary results very early on.
Every time I showed my work to a JavaScript developer, I'd get negative feedback. Like, unjustified hatred and immediate denial, or outright rejection of the entire concept. Some were even adamantly trying to discourage me from this project.
So I posted a sarcastic question to the Software Engineering Stack Exchange, which was originally worded differently to reflect my frustration, but was later edited by mods to be more serious.
You can see the responses for yourself here: https://goo.gl/poHKpK
Most of the serious answers were along the lines of "multithreading is hard". The top voted response started with this statement: "1) Multithreading is extremely hard, and unfortunately the way you've presented this idea so far implies you're severely underestimating how hard it is."
While I'll admit that my presentation was initially lacking, I later made an entire page to explain the synchronisation mechanism in place, and you can read more about it here, if you're interested:
http://nexusjs.com/architecture/
But what really shocked me was that I had never understood the mindset that all the naysayers adopted until I read that response.
Because the bottom-line of that entire response is an argument: an argument against change.
The average JavaScript developer doesn't want a multithreaded server platform for JavaScript because it means a change of the status quo.
And this is exactly why I started this project. I wanted a highly performant JavaScript platform for servers that's more suitable for real-time applications like transcoding, video streaming, and machine learning.
Nexus does not and will not hold your hand. It will not repeat Node's mistakes and give you nice ways to shoot yourself in the foot later, like `process.on('uncaughtException', ...)` for a catch-all global error handling solution.
No, an uncaught exception will be dealt with like any other self-respecting language: by not ignoring the problem and pretending it doesn't exist. If you write bad code, your program will crash, and you can't rectify a bug in your code by ignoring its presence entirely and using duct tape to scrape something together.
Back on the topic of multithreading, though. Multithreading is known to be hard, that's true. But how do you deal with a difficult solution? You simplify it and break it down, not just disregard it completely; because multithreading has its great advantages, too.
Like, how about we talk performance?
How about distributed algorithms that don't waste 40% of their computing power on agent communication and pointless overhead (like the serialisation/deserialisation of messages across the execution boundary for every single call)?
How about vertical scaling without forking the entire address space (and thus multiplying your application's memory consumption by the number of cores you wish to use)?
How about utilising logical CPUs to the fullest extent, and allowing them to execute JavaScript? Something that isn't even possible with the current model implemented by Node?
Some will say that the performance gains aren't worth the risk. That the possibility of race conditions and deadlocks aren't worth it.
That's the point of cooperative multithreading. It is a way to smartly work around these issues.
If you use promises, they will execute in parallel, to the best of the scheduler's abilities, and if you chain them then they will run consecutively as planned according to their dependency graph.
If your code doesn't access global variables or shared closure variables, or your promises only deal with their provided inputs without side-effects, then no contention will *ever* occur.
If you only read and never modify globals, no contention will ever occur.
Are you seeing the same trend I'm seeing?
Good JavaScript programming practices miraculously coincide with the best practices of thread-safety.
When someone says we shouldn't use multithreading because it's hard, do you know what I like to say to that?
"To multithread, you need a pair."18 -
I'm a tech lead for a digital agency.
Digital agencies are universally known for being shite. Why? Because they typically push through sub-optimal code with very little testing over tiny deadlines for maximum profit. Maybe I've just had bad experiences but this is the 5th digital agency that I've worked at that does this bollocks.
I am currently sitting on a Teams call at 8:39pm because the fuckwit project/account managers are unable to face up to the big scary client and ask them terrifying questions like "Is this bug a blocker for the deployment?" or "We don't have enough time to fix/change these things, can we delay another day?". They just assume that A - We will work into the evening, and B - that all the issues are P1 and that we should all 'pull together' as 'team players' to get this done in time.
No, Me and my team have to work into the evening for seemingly free because these pricks can't do their jobs properly.
The funniest thing of all? When I speak to the CTO about overtime payment he tries to make me feel bad about "we don't typically pay for overtime..."
Fuck Everyone.
Time to find a new contract.11 -
So today, I managed to make one of my colleagues feel like an idiot. In this contract, I work mostly for ui integration, while he build the pages with angular before I add all the html structure and fancy css.
We are building the front-end/ui for an industrial device with a touch screen. For that last 2 days he was blocked on a bug that when you click the confirm button on a delete popup, it would somehow select an input in the page before it was deleted and would lock the ui when showing the virtual keyboard (the poor thing didn't know what to do and wouldn't close).
During those two days, he asked all the other devs for help, trying to find a pattern or anything that could help, while I was focused on writing my css and stuff since it was my priority and I was hired specifically for that (I was aware of the bug and gave my input but I never saw it being reproduced)
So today, he start his new routine of raging at his desk and he decides to show me on my device for some reason. I immediately notice a pattern. It would always select one of the two fields behind the popup, in the click area of the button (it's a big button). Then, I noticed that I could press a random spot on the screen, drag my finger on the button and let go and nothing would happen.
It's at this moment I knew I had found the bug. The button was set to emit an event on mousedown while the inputs behind it were set to emit an event on mouseup (like it should be everywhere). So the popup closed when you placed your finger on the screen and the input was selected immediately after when you removed your finger (which was usually faster than the page code which was not yet optimized)
After that, it was just an easy fix to change the listener and I had a free beer.1 -
Programmer Influencers piss me off to Jupiter and back.
The ones who talk about just being a programmer, and don't do normal tutorials and solve a real-world problem and demonstrate it.
"i iNcREaSeD mY pRoDuCTiViTy bY 90%. hErE's HoW"
"tOp 10 lAnGuAGeS yOu sHoUlD lEaRn iN 2023"
"dAy iN thE LiFe oF a SoFtWaRe EnGiNeEr"
"HeRE's hOw yOu cAn wRiTe bUg fReE cOdE"13 -
I explained my latest project to a non developer friend. I told him I'm almost done with the code, now I just need to debug and get it ready for production.
"Why don't you write code that doesn't have any bugs?"
"Holy shit! I never thought about that! Thank you so much, I'll make sure to write bug free code from now on".10 -
Hey guys,
this rant will be long again. I'm sorry for any grammar errors or something like that, english isn't my native language. Furthermore I'm actually very sad and not in a good mood.
Why? What happened? Some of you may already know - I'm doing my apprenticeship / education in a smal company.
There I'm learning a lot, I'm developing awesome features directly for the clients, experience of which other in my age (I'm only 19 years old) can only dream.
Working in such a small company is very exhausting, but I love my job, I love programming. I turned my hobby into a profession and I'm very proud of it.
But then there are moments like the last time, when I had to present something for a client - the first presentation was good, the last was a disaster, nothing worked - but I learned from it.
But this time everything is worse than bad - I mean really, really worse than bad.
I've worked the whole week on a cool new feature - I've done everything that it works yesterday, that everything gets done before the deadline of yesterday.
To achieve this I've coded thursday till 10pm ! At home! Friday I tested the whole day everything to ensure that everything is working properly. I fixed several bugs and then at the end of the day everything seems to be working. Even my boss said that it looks good and he thinks that the rollout to all clients will become good and without any issues.
But unfortunately deceived.
Yesterday evening I wrote a long mail to my boss - with a "manual". He was very proud and said that he is confident that everything will work fine. He trusts me completly.
Then, this morning I received a mail from him - nothing works anymore - all clients have issues, everything stays blank - because I've forgotten to ensure that the new feature (a plugin) and its functionality is supported by the device (needs a installation).
First - I was very shoked - but in the same moment I thought - one moment - you've written an if statement, if the plugin is installed - so why the fuck should it broken everything?!
I looked instant to the code via git. This has to be a very bad joke from my boss I thought. But then I saw the fucking bug - I've written:
if(plugin) { // do shit }
but it has to be if(typeof plugin !== 'undefined')
I fucked up everything - due to this fucking mistake. This little piece of shit I've forgotten on one single line fucked up everything. I'm sorry for this mode of expression but I thought - no this can not be true - it must be a bad bad nightmare.
I've tested this so long, every scenario, everything. Worked till the night so it gets finished. No one, no one from my classmates would ever think of working so long. But I did it, because I love my job. I've implemented a check to ensure that the plugin is installed - but implemented it wrong - exactly this line which caused all the errors should prevent exactly this - what an irony of fate.
I've instantly called my boss and apologized for this mistake. The mistake can't be undone. My boss now has to go to all clients to fix it. This will be very expensive...
Oh my goodnes, I just cried.
I'm only working about half a year in this company - they trust me so much - but I'm not perfect - I make mistakes - like everyone else. This time my boss didn't looked over my code, didn't review it, because he trusted me completly - now this happens. I think this destroyed the trust :( I'm so sad.
He only said that we will talk on monday, how we can prevent such things in the feature..
Oh guys, I don't know - I've fucked up everything, we were so overhelmed that everything would work :(
Now I'm the looser who fucked up - because not testing enough - even when I tested it for days, even at home - worked at home - till the night - for free, for nothing - voluntary.
This is the thanks for that.
Thousand good things - but one mistake and you're the little asshole. You - a 19 year old guy, which works since 6 months in a company. A boss which trusts you and don't look over your code. One line which should prevent crashing, crashed everything.
I'm sorry that this rant is so long, I just need to talk to you guys because I'm so sad. Again. This has happend to frequently lately.16 -
Tl;Dr - It started as an escape, carried on as fun, then as a way to be lazy, and finally as a way of life. Coding has defined and shaped my entire life from the age of nine.
When I was nine I was playing a game on my ZX spectrum and accidentally knocked the keyboard as I reached over to adjust my TV. Incredibly parts of it actually made a little sense to me and got my curiosity. I spent hours reading through that code, afraid to turn the Spectrum off in case I couldn't get back to it. Weeks later I got hold of a book of example code to copy out to do various things like making patterns on the screen. I was amazed by it. You told it what to do, and it did it! (don't you miss the days when coding worked like that?) I was bitten by the coding bug (excuse the pun) and I'd got it bad! I spent many late nights on that thing, escaping from a difficult home life. People (especially adults) were confusing, and in my experience unpredictable. When you did things wrong they shouted at you and threatened to take you away, or ignored you completely. Code never did that. If you did something wrong, it quietly let you know and often told you exactly what was wrong. It wasn't because of shifting expectations or a change of mood or anything like that. It was just clean logic, simple cause and effect.
I get my first computer a year later: an IBM XT that had been discarded by a company and was fitted with a key on the side to turn it on. With the impressive noise it made it really was like starting an engine. Whole most kids would have played with the games, I spent my time playing with batch scripts and writing very simple text adventures. And discovering what "format c:" does. With some abuse and threatened violence I managed to get windows running on it. Windows 2.1 I think it was.
At 12 I got a Gateway 75 running Windows 95. Over the next few years I do covered many amazing games: ROTT, Doom, Hexen, and so on. Aside from the games themselves, I was fascinated by the way computers could be linked together to play together (this was still early days for the Web and computers networked in a home was very unusual). I also got into making levels for Doom, Heretic, and years later Duke Nukem 3D (pretty sure it was heretic; all I remember is the nightmare of trying to write levels entirely by code!). I enjoyed re-scripting some of the weapons and monsters to behave differently. About this time I also got into HTML (I still call this coding, but not programming), C, and java. I had trouble with C as none of the examples and tutorial code seemed to run properly under a Windows environment. Similar for my very short stint with assembly. At some point I got a TI-83 programmable calculator and started rewriting my old batch script games on it, including one "Gangster Lord" game that had the same mechanics as a lot of the Facebook games that appeared later (do things, earn money, spend money to buy stuff to do more things). Worried about upcoming exams, I also made a number of maths helper apps, including a quadratic equation solver that gave the steps, and a fake calculator reset to smuggle them into my exams. When the day came I panicked and did a proper reset for fear of being caught.
At 18 I was convinced I was going to be a professional coder as I started a degree in Computer Science. Three months later I dropped out after a bunch of lectures teaching what input and output devices were and realising we were only going to be taught Java and no C++. I started a job on the call centre of a big company, but was frustrated with many of the boring and repetitive tasks we had to do. So I put my previous knowledge to use, and quickly learned VBA to automate tasks. It wasn't long before I ended up promoted to Business Analyst where I worked on a great team building small systems in Office, SAS, and a few other tools.
I decided to retrain in psychology, so left the job I was in and started another degree. During my work and placements my skills came in use a number of times to simplify and automate tasks. I finished my degree, then took a job as a teaching assistant while I worked out what I wanted to do next and how to pay for it. Three years later I've ended up IT technican at the school, responsible for the website, teaching a number of Computing lessons each week, and unofficial co-coordinator for Computing as a subject. I also run a team of ten year old Digital Leaders who I am training in online safety and as technical experts; I am hoping to inspire them to a future in coding. In September I'll be starting teacher training with a view to becoming a Computing specialist teacher. Oh, and I'm currently doing a course in Android Development in my free time.
And this all started with an accidental knock on the keyboard of a ZX Spectrum.6 -
Before a month I wrote I would like to create my own pastebin-like service.
And here it is... Pastitude!
End-to-end encrypted open-source service for sharing your awesome code :)
Tell me your opinions for this project in comments. Feel free to create an issue if you found any bug or have an idea how to improve Pastitude.
https://pastitude.com
GitHub link: https://github.com/PapiCZ/pastitude16 -
You know what really grinds my gears? As a junior webdeveloper (mostly backend) I try my hardest to deliver quality content and other people's ignorance is killing me in my current job.
Let's rant about a recent project I had under my hood, for this project (a webshop) I had to restructure the database and had to include validation on basicly every field (what the heck, no validation I hear you say??), apperently they let an incompetent INTERN make this f***king webshop. The list of mistakes in this project can bring you close to the moon I'd say, seriously.
Database design 101 is basicly auto incremented ID's, and using IDs in general instead of using name (among a list of other stuff obv.). Well, this intern decided it was a good idea to filter a custom address-book module based on a NAME, so it wasn't setup as: /addressbook/{id} (unique ID, never a problem) but as /addressbook/{name}, which results in only showing one address if the first names on the addresses are the same. Lots of bugs that go by this type of incompetence and ignorance. Want to hear another joke? Look no further, this guy also decided it was a great idea to generate the next ID of an order. So the ordernumber wasn't made up by the auto incremented id on the order model, but by a count of all the orders and that was the next order number. This broke so many times, unbelievable.
To close the list of mistakes off, the intern decided it was a great idea to couple the address of a user directly to an order. Because the user is able to ship stuff to addresses within his addressbook, this bug could delete whole orders out of the system by simply deleting the address in your addressbook.
Enough about my intern rant, after working my ass of and going above and beyond the expectations of the customer, the guy from sales who was responsible for it showed what an a**hole he was. Lets call this guy Tom.
Little backstory: our department is a very small part of the company but we are responsible for so much if you think about it. The company thinks we've transitioned to company wide SCRUM, but in reality we are so far from it. I think the story below is a great example of what causes this.
Anyway, we as the web department work within Gitlab. All of our issues and sprints are organized and updated within this place. The rest of the company works with FileMaker, such a pile of shit software but I've managed to work around its buggyness. Anyway, When I was done with the project described above I notified all the stakeholders, this includes Tom. I made a write-up of all the changes I had made to the project, including screenshots and examples, within Gitlab. I asked for feedback and made sure to tag Tom so he was notified of my changes to the project.
After hearing nothing for 2 weeks, guess who came to my desk yesterday? F**king tom asking what had changed during my time on the project. I told him politely to check Gitlab and said on a friendly tone that I had notified him over 2 weeks ago. He, I shit you not, blantly told me that he never looks on there "because of all the notifications" and that I should 'tell him what to do' within FileMaker (which I already had updated referencing Gitlab with the write-up of my changes). That dick move of him made me lose all respect for this guy, what an ignorant piece of shit he is afterall.
The thing that triggers me the most in the last story is that I spent so much free time to perfect the project I was working on (the webshop). I even completed some features which weren't scheduled during the sprint I was working on, and all I was asking for was a little appreciation and feedback. Instead, he showed me how ignorant and what a dick he was.
I absolutely have no reason to keep on working for this company if co-workers keep treating me like this. The code base of the webshop is now in a way better condition, but there are a dozen other projects like this one. And guess what? All writen by the same intern.
/rant :P10 -
I spent over a decade of my life working with Ada. I've spent almost the same amount of time working with C# and VisualBasic. And I've spent almost six years now with F#. I consider all of these great languages for various reasons, each with their respective problems. As these are mostly mature languages some of the problems were only knowable in hindsight. But Ada was always sort of my baby. I don't really mind extra typing, as at least what I do, reading happens much more than writing, and tab completion has most things only being 3-4 key presses irl. But I'm no zealot, and have been fully aware of deficiencies in the language, just like any language would have. I've had similar feelings of all languages I've worked with, and the .NET/C#/VB/F# guys are excellent with taking suggestions and feedback.
This is not the case with Ada, and this will be my story, since I've no longer decided anonymity is necessary.
First few years learning the language I did what anyone does: you write shit that already exists just to learn. Kept refining it over time, sometimes needing to do entire rewrites. Eventually a few of these wound up being good. Not novel, just good stuff that already existed. Outperforming the leading Ada company in benchmarks kind of good. At the time I was really gung-ho about the language. Would have loved to make Ada development a career. Eventually build up enough of this, as well as a working, but very bad performing compiler, and decide to try to apply for a job at this company. I wasn't worried about the quality of the compiler, as anyone who's seriously worked with Ada knows, the language is remarkably complex with some bizarre rules in dark corners, so a compiler which passes the standards test indicates a very intimate knowledge of the language few can attest to.
I get told they didn't think I would be a good fit for the job, and that they didn't think I should be doing development.
A few months of rapid cycling between hatred and self loathing passes, and then a suicide attempt. I've got past problems which contributed more so than the actual job denial.
So I get better and start working even harder on my shit. Get the performance of my stuff up even better. Don't bother even trying to fix up the compiler, and start researching about text parsing. Do tons of small programs to test things, and wind up learning a lot. I'm starting to notice a lot of languages really surpassing Ada in _quality of life_, with things package managers and repositories for those, as well as social media presence and exhaustive tutorials from the community.
At the time I didn't really get programming language specific package managers (I do now), but I still brought this up to the community. Don't do that. They don't like new ideas. Odd for a language which at the time was so innovative. But social media presence did eventually happen with a Twitter account that is most definitely run by a specific Ada company masquerading as a general Ada advocate. It did occasionally draw interest to neat things from the community, so that's cool.
Since I've been using both VisualStudio and an IDE this Ada company provides, I saw a very jarring quality difference over the years. I'm not gonna say VS is perfect, it's not. But this piece of shit made VS look like a polished streamlined bug free race car designed by expert UX people. It. Was. Bad. Very little features, with little added over the years. Fast forwarding several years, I can find about ten bugs in five minutes each update, and I can't find bugs in the video games I play, so I'm no bug finder. It's just that bad. This from a company providing software for "highly reliable systems"...
So I decide to take a crack at writing an editor extension for VS Code, which I had never even used. It actually went well, and as of this writing it has over 24k downloads, and I've received some great comments from some people over on Twitter about how detailed the highlighting is. Plenty of bespoke advertising the entire time in development, of course.
Never a single word from the community about me.
Around this time I had also started a YouTube channel to provide educational content about the language, since there's very little, except large textbooks which aren't right for everyone. Now keep in mind I had written a compiler which at least was passing the language standards test, so I definitely know the language very well. This is a standard the programmers at these companies will admit very few people understand. YouTube channel met with hate from the community, and overwhelming thanks from newcomers. Never a shout out from the "community" Twitter account. The hate went as far as things like how nothing I say should be listened to because I'm a degenerate Irishman, to things like how the world would have been a better place if I was successful in killing myself (I don't talk much about my mental illness, but it shows up).
I'm strictly a .NET developer now. All code ported.5 -
My job in a nutshell:
*fixes app, so it's working 99% bug free*
*Chrome update*
*app is full of bugs*
*fixes bugs*
*iOS 10 comes out*
*app is full of bugs*
*fixes bugs*
"we can now remove iOS7 support"
*removes code*
*app is full of bugs*
For fucks sake!!2 -
When I had to postpone the release of v2 of devRant UWP for 3 months because I changed a few minutes before the final build a "loaded" event to a "loading" event.
Something that for some stupid reason I thought will make the startup faster (maybe by 2ms) has caused crashes on mobile and some Windows 10 versions.
Of course I didn't spend 3 months to find this bug, but at least a few days in December and then I didn't have enough free time so I had to stop until mid February when I finally fixed it.
To find the reason I reverted the code to the previous update and started to add every feature one by one.
So much time wasted for a fucking "-ing". -
In my three years experience so far I can honestly say that 100% of the developers I've worked with are narrow sighted with regards to how they develop.
As in, they lack the capacity to anticipate multiple scenarios.
They code with one unique scenario in mind and their work ends up not passing tests or generates bugs in production.
Not to say I'm the best at foreseeing every possible scenario, but I at least TRY to anticipate and test my code as much as possible to identify problems and edge cases.
I usually take much more time to complete tasks than my colleagues, but my work usually passes tests and comes back bug free. Whereas my colleagues get applauded for completing tasks quickly but end up spending lots of time fixing up after themselves when tests fail or bugs appear.
Probably more time wasted than if they had done the job correctly from the start. Yet they're considered to be effecient devs because they work "fast".
Frustrating...7 -
One night, after one very stressful week of production code fixes (I was working on a game with some friends and I created the network infrastructure for P2P and database communication from scratch), I was at my gf's house. After we fell asleep, I stood up and screamed right at her something like "I fucking already told you how X works and how to communicate with Y. Learn to write code properly and after double checking yours then you shall ask me for a non-existing 'bug' fix. Learn how to properly write event based code and use polling you moron!". After that I turned to the other side and fell asleep immediately.
When I saw her the next morning sleeping in the couch, I could not understand why... Only after she described to me the whole incident I started laughing.
After that I just took two weeks off the project and after that period I never actually worked the same way (so hard) in my free time with them.1 -
When I was a kid :
- Bugs eat grass
Now:
- Bugs eat time
I still wonder when will the day come when I write bug-free code in my first attempt (:(8 -
Github 101 (many of these things pertain to other places, but Github is what I'll focus on)
- Even the best still get their shit closed - PRs, issues, whatever. It's a part of the process; learn from it and move on.
- Not every maintainer is nice. Not every maintainer wants X feature. Not every maintainer will give you the time of day. You will never change this, so don't take it personally.
- Asking questions is okay. The trackers aren't just for bug reports/feature requests/PRs. Some maintainers will point you toward StackOverflow but that's usually code for "I don't have time to help you", not "you did something wrong".
- If you open an issue (or ask a question) and it receives a response and then it's closed, don't be upset - that's just how that works. An open issue means something actionable can still happen. If your question has been answered or issue has been resolved, the issue being closed helps maintainers keep things un-cluttered. It's not a middle finger to the face.
- Further, on especially noisy or popular repositories, locking the issue might happen when it's closed. Again, while it might feel like it, it's not a middle finger. It just prevents certain types of wrongdoing from the less... courteous or common-sense-having users.
- Never assume anything about who you're talking to, ever. Even recently, I made this mistake when correcting someone about calling what I thought was "powerpc" just "power". I told them "hey, it's called powerpc by the way" and they (kindly) let me know it's "power" and why, and also that they're on the Power team. Needless to say, they had the authority in that situation. Some people aren't as nice, but the best way to avoid heated discussion is....
- ... don't assume malice. Often I've come across what I perceived to be a rude or pushy comment. Sometimes, it feels as though the person is demanding something. As a native English speaker, I naturally tried to read between the lines as English speakers love to tuck away hidden meanings and emotions into finely crafted sentences. However, in many cases, it turns out that the other person didn't speak English well enough at all and that the easiest and most accurate way for them to convey something was bluntly and directly in English (since, of course, that's the easiest way). Cultures differ, priorities differ, patience tolerances differ. We're all people after all - so don't assume someone is being mean or is trying to start a fight. Insinuating such might actually make things worse.
- Please, PLEASE, search issues first before you open a new one. Explaining why one of my packages will not be re-written as an ESM module is almost muscle memory at this point.
- If you put in the effort, so will I (as a maintainer). Oftentimes, when you're opening an issue on a repository, the owner hasn't looked at the code in a while. If you give them a lot of hints as to how to solve a problem or answer your question, you're going to make them super, duper happy. Provide stack traces, reproduction cases, links to the source code - even open a PR if you can. I can respond to issues and approve PRs from anywhere, but can't always investigate an issue on a computer as readily. This is especially true when filing bugs - if you don't help me solve it, it simply won't be solved.
- [warning: controversial] Emojis dillute your content. It's not often I see it, but sometimes I see someone use emojis every few words to "accent" the word before it. It's annoying, counterproductive, and makes you look like an idiot. It also makes me want to help you way less.
- Github's code search is awful. If you're really looking for something, clone (--depth=1) the repository into /tmp or something and [rip]grep it yourself. Believe me, it will save you time looking for things that clearly exist but don't show up in the search results (or is buried behind an ocean of test files).
- Thanking a maintainer goes a very long way in making connections, especially when you're interacting somewhat heavily with a repository. It almost never happens and having talked with several very famous OSSers about this in the past it really makes our week when it happens. If you ever feel as though you're being noisy or anxious about interacting with a repository, remember that ending your comment with a quick "btw thanks for a cool repo, it's really helpful" always sets things off on a Good Note.
- If you open an issue or a PR, don't close it if it doesn't receive attention. It's really annoying, causes ambiguity in licensing, and doesn't solve anything. It also makes you look overdramatic. OSS is by and large supported by peoples' free time. Life gets in the way a LOT, especially right now, so it's not unusual for an issue (or even a PR) to go untouched for a few weeks, months, or (in some cases) a year or so. If it's urgent, fork :)
I'll leave it at that. I hear about a lot of people too anxious to contribute or interact on Github, but it really isn't so bad!4 -
Ah, developers, the unsung heroes of caffeine-fueled coding marathons and keyboard clacking symphonies! These mystical beings have a way of turning coffee and pizza into lines of code that somehow make the world go 'round.
Have you ever seen a developer in their natural habitat? They huddle in dimly lit rooms, surrounded by monitors glowing like magic crystals. Their battle cries of "It works on my machine!" echo through the corridors, as they summon the mighty powers of Stack Overflow and Google to conquer bugs and errors.
And let's talk about the coffee addiction – it's like they believe caffeine is the elixir of code immortality. The way they guard their mugs, you'd think it's the Holy Grail. In fact, a developer without coffee is like a computer without RAM – it just doesn't function properly.
But don't let their nerdy exteriors fool you. Deep down, they're dreamers. They dream of a world where every line of code is bug-free and every user is happy. A world where the boss understands what "just one more line of code" really means.
Speaking of bosses, developers have a unique ability to turn simple requests into complex projects. "Can you make a small tweak?" the boss asks innocently. And the developer replies, "Sure, it's just a minor change," while mentally calculating the time it'll take and the potential for scope creep.
Let's not forget their passion for acronyms. TLA (Three-Letter Acronym) is their second language. API, CSS, HTML, PHP, SQL... it's like they're playing a never-ending game of Scrabble with abbreviations.
And documentation? Well, that's their arch-nemesis. It's as if writing clear instructions is harder than debugging quantum mechanics. "The code is self-explanatory," they claim, leaving everyone else scratching their heads.
In the end, developers are a quirky bunch, but we love them for it. Their quirks and peculiarities are what make them the creative, brilliant minds that power our digital world. So here's to developers, the masters of logic and the wizards of the virtual realm!13 -
"Bu...bu..but JAVA SWING and FX are PORTABLE!"
And electrolytes are what plants crave.
I swear half the people I argue with are dinks.
IF YOU HAVE PEOPLE YOU ARE RESPONSIBLE FOR YOU HAVE TO DO WORK PEOPLE WILL HIRE YOU FOR.
Under job listings for javafx: 2 listings within 200 miles of me.
Under job listings for C#/WPF: dozens and dozens of jobs.
Portability doesn't matter if you're broke.
My stomach owes no allegiance to "high fallutin" concepts such as openness, avoiding vendor lock in, or the high ideals of platform independence.
I'll take the microsoft gulag if it pays my bills.
I don't know whats so hard to grasp about this. Some people are completely divorced from reality.
Edit: Hello to all my peeps who I haven't talked with in a while. I hope everything is going swimmingly in your lives. May your beer forever be paid for by your employer and your code bug free!5 -
I could kill someone. My boss occupied the whole cluster for 24h yesterday, so that I had to wait until today to see that I had a small bug in my code. I wasted a whole day waiting around for something I could have fixed in 5 minutes yesterday if I only had 1 free node on the cluster 😠
Worst of all, if anybody else had occupied the whole cluster for so long without asking, he would have sent an angry e-mail to the whole institute 😠4 -
Our Code everlasting
The all creating One
Coders Almighty
Through Our Holy Lines
Conceiving Algorithms
Konrad Zuse our Savior
I believe in Clean Code
I believe in Free Software
I believe in Open Source
Our Code is three in one
I believe in the bug-free project
That'll be compiled again
For I believe in the name of Alan Turing -
How to write bug free code:
while True:
try:
_loop() # all logic here
except:
print_excv()
This will not cause any difficulties ever. Remember to pipe output to /dev/null, make this script a critical but undocumented part of your infrastructure and tell no one about it. -
Fun fact : Typing on a keyboard that's not plugged into your laptop will not work. Honestly, I should have taken today off. My toddler woke up at 1am screaming bloody murder and didn't get back to bed until 2:30. There's a construction crew hammering up my 14 year old floors to replace it with new ones. My dog is anxious as fuck with all the noise, and truthfully, I'm just staring into my screen hoping the code will write itself. This code will become production deployment logic, so it damn well better be excellent and bug-free. Not a good day to pick up this task.3
-
You cant be a recognzied as a good developer, untill you are a good tester or say produce least bug free code. You should do thorough testing of your code before handing over to QA. I lacked the skill of good unit testing, so have suffered alot in past years.1
-
If you say u can write a bug free code, thats a bigger news than AlphaGo.
#alphaGo
#awesome_documentary 👏👏1 -
"Whenever there is a decline in quality of code and rise of bugs and errors oh dear coder, I manifest to show the path of bug and error free coding" said code-god
- Chapter 1 Verse 1, Code Gita -
Give me your legacy, your undocumented,
Your huddled classss yearning to be bug free,
The wretched security holes of your multiple backdoors.
Send these, the testless, spaghetti-code to me,
I lift my keyboard beside the golden door! -
Linux is great - to tinker, to pull in all your FOSS, mess around...
But it's so fucked up, if you actually build and maintain a product on it, i.e. try to distribute s.th. in binary for money even. It's just not intended. If you offer your code for free, you can always say: "Ah, just compile it yourself. You might need these 29 dependencies, of which 2 are not even checked by configure, oops, and now it crashes, maybe in that qt library version, you picked there's still a bug?.. you know, it worked on my machine, sorry."
But if you sell it, it better install and run! And even if you target only the main distros of all that fragmented Linuverse - let's say, Debian, Ubuntu, RHEL, CentOS, Fedora, and if you're in Germany OpenSuSE and SLES, you'll start to see the crap of work you're up with. What you could try is to orchestrate a docker fleet with one container per distro, where you take the oldest version you still support compile a newer gcc there (to at least have C++11) and all your third party libs and then hope the resulting binary runs on all the newer versions of that distro, too.
(You could even be so brave as to try to pick a deb and rpm distro to build for all other distros.)
But ABI incompatibility can still bite you. For instance we once had the insane case, that our GUI would no longer start just by switching the Window-Manager to KDE.8 -
Today I read a great article on mutation tests, how to use and why they are important. It looks like a great thing, but...
I have never wrote any unit test in any of my jobs. Nobody in my workplace does that. And now it seems like 100% test coverage is not enough (I remind you, that I have 0%), they all should mutate to check if the quality of unit tests is high.
It seems that I'm left behind. I played with tests in my free time, but it seems the more you write them, the better you get at it, so I should be writing them in my job, where I code most of my time. Not only that, of course, I would also want to ensure that what I'm working on is bug-free.
Still, it will be impossible to introduce unit tests to my project, because they are novelty to the whole team and our deadlines are tight. The other thing is, we are supposed to write minimum viable product, as it is a demo for a client, and every line of code matters. Some might say that we are delusional that after we finish demo we will make things the right way.
Did any one of you have a situation like this? How did you change your boss and team's mind?8 -
The Odyssey of the Tenacious Tester:
Once upon a time in the digital kingdom of Binaryburg, there lived a diligent software tester named Alice. Alice was on a mission to ensure the flawless functionality of the kingdom's latest creation – the Grand Software Citadel.
The Grand Software Citadel was a marvel, built by the brilliant developers of Binaryburg to serve as the backbone of all digital endeavors. However, with great complexity came an even greater need for meticulous testing.
Alice, armed with her trusty testing toolkit, embarked on a journey through the intricate corridors of the Citadel. Her first challenge was the Maze of Edge Cases, where unexpected scenarios lurked at every turn. With a keen eye and a knack for uncovering hidden bugs, Alice navigated the maze, leaving no corner untested.
As she progressed, Alice encountered the Chamber of Compatibility, a place where the Citadel's code had to dance harmoniously with various browsers and devices. With each compatibility test, she waltzed through the intricacies of cross-browser compatibility, ensuring that the Citadel would shine on every screen.
But the true test awaited Alice in the Abyss of Load and Performance. Here, the Citadel's resilience was put to the test under the weight of simulated user hordes. Alice, undeterred by the mounting pressure, unleashed her army of virtual users upon the software, monitoring performance metrics like a hawk.
In the end, after days and nights of relentless testing, Alice emerged victorious. The Grand Software Citadel stood strong, its code fortified against the perils of bugs and glitches.
To honor her dedication, the software gods bestowed upon Alice the coveted title of Bug Slayer and a badge of distinction for her testing prowess. The testing community of Binaryburg celebrated her success, and her story became a legend shared around digital campfires.
And so, dear software testers, let the tale of Alice inspire you in your testing quests. May your test cases be thorough, your bug reports clear, and your software resilient against the challenges of the digital realm.
In the world of software testing, every diligent tester is a hero in their own right, ensuring that the digital kingdoms stand tall and bug-free. -
Real question, not troll. There is debate about it and I really can't figure it out.
Besides having the title software "engineer," is there really such a thing as a software engineer?
In the US, to be an engineer you have to be regularly tested by a regulated governing body, apprentice under another engineer for years, and be certified on a state level. Whereupon you are personally liable for your designs being FREE from errors.
For one thing, nobody can write bug free code, and the idea of being personally responsible for each bug is terrifying.
And two, I've seen news of people calling themselves software engineers in the USA and Canada and getting a cease and desist or sued for it, despite any level of qualification.
I'm sure there are engineers, especially electrical, computer engineers who also program.
But... ?
I don't know, I can't say either way.
That's why I'm asking.9 -
Well fuck. I am experiencing over-engineering first hand.
I am the single dev responsible for developing a small feature but which is an identity to our whole product(feel free to guess it here). This is quite simple I thought, I can just modify the constants which are being used in the source code and I can finish it off in a week tops. I asked all the relevant teams over which this feature would have dependencies and they gave me a green signal. Setup Jenkins configuration and everything for this new feature. With a wide grin on my face, I sent out a pull request. Now the architect of our product declined the pr saying to change everything from the bottom up giving the reason that it would be configurable sometime later in the future. Now mind you, I get it if this feature could change over time and needs customability. But it has been the same since last seven years and would probably not change again for a couple of years ahead [you have to take my word for it.]. Its not that the guy is a douche or anything, he is one of the best dev I have ever personally came across and I highly respect and admire him. But there has to be a trade off between the effort you are putting in versus the benefit you get. Now I have to touch almost every file, super carefully look in the whole product if a bug creeps out from anywhere and change the existing code to a point where it doesn't even make sense to me anymore, and write tests ofcourse.
wubba lubba dub dub!2 -
Was working on a high priority security feature. We had an unreasonable timeline to get all of the work done. If we didn’t get the changes onto production before our deadline we faced the possibility of our entire suit being taken offline. Other parts of the company had already been shut down until the remediations could be made -so we knew the company execs weren’t bluffing.
I was the sole developer on the project. I designed it, implemented it, and organized the efforts to get it through the rest of the dev cycle. After about 3 month of work it was all up and bug free (after a few bugs had been found and squashed). I was exhausted, and ended up taking about a week and a half off to recharge.
The project consisted of restructuring our customized frontend control binding (asp.net -custom content controls), integrations with several services to replace portions of our data consumption and storage logic, and an enormous lift and shift that touched over 6k files.
When you touch this much code in such a short period of time it’s difficult to code review, to not introduce bugs, and _to not stop thinking about what potential problems your changes may be causing in the background_.3 -
I'm an iOS developer and I cringe when I read job specs that require TDD or excessive unit testing. By excessive I mean demanding that unit tests need to written almost everywhere and using line coverage as a measure of success. I have many years of experience developing iOS apps in agencies and startups where I needed to be extremely time efficient while also keeping the code maintainable. And what I've learned is the importance of DRY, YAGNI and KISS over excessive unit testing. Sadly our industry has become obsessed with unit tests. I'm of the opinion that unit tests have their place, but integration and e2e tests have more value and should be prioritised, reserving unit tests for algorithmic code. Pushing for unit tests everywhere in my view is a ginormous waste of time that can't ever be repaid in quality, bug free code. Why? Because leads to making code testable through dependency injection and 'humble object' indirection layers, which increases the LoC and fragments code that would be easier to read over different classes. Add mocks, and together with the tests your LoC and complexity have tripled. 200% code size takes 200% the time to maintain. This time needs to be repaid - all this unit testing needs to save us 200% time in debugging or manual testing, which it doesn't unless you are an absolute rookie who writes the most terrible and buggy code imaginable, but if you're this terrible writing your production code, why should your tests be any better? It seems that especially big corporate shops love unit tests. Maybe they have enough money and resources to pay for all these hours wasted on unit tests. Maybe the developers can point their 10,000 unit tests when something goes wrong and say 'at least we tried'? Or maybe most developers don't know how to think and reason about their code before they type, and unit tests force them to do that?12
-
YouTube first what's it's about or get information about the tech. Next, look for free tutorials on YouTube.
When working on the tech, use Google to look to bug-fix or code that some might have already written. -
I saw a thing on the Workplace stack exchange site. This college kid with no in industry experience read the false narrative that "pitting your testers against your developers for bonus money encourages better productivity and bug free code". And thought it sounded good on paper. This worries me in many ways (especially since he wants to make a startup). The first being that he couldn't see how both sides would game the hell out of such a system, which I feel any worthwhile engineer types would easily figure out. The second is seeing money as the major motivating force behind software devs doing their jobs. I had a third but I am tired.
But seriously, who is still writing this bullshit (that article, not the kid's question) in 2016? -
https://stilldrinking.org/programmi...
/\ This is why all programmers should go on strike for a month and collectively collaborate to code a new, clean, bug free internet where nobody but you can control your data.
Also. It should only be added to by people who know how to code in order to maintain this clean code.
We can call it "internet level 2" or "internet 2.0"4 -
"The Perils and Triumphs of Debugging: A Developer's Odyssey"
You know you're in for an adventurous coding session when you decide to dive headfirst into debugging. It's like setting sail on the tumultuous seas of code, not quite sure if you'll end up on the shores of success or stranded on the island of endless errors.
As a developer, I often find myself in this perilous predicament, armed with my trusty text editor and a cup of coffee, ready to conquer the bugs lurking in the shadows. The first line of code looks innocent enough, but little did I know that it was the calm before the storm.
The journey begins with that one cryptic error message that might as well be written in an ancient, forgotten language. It's a puzzle, a riddle, and a test of patience all rolled into one. You read it, re-read it, and then call over your colleague, hoping they possess the magical incantation to decipher it. Alas, they're just as clueless.
With each debugging attempt, you explore uncharted territories of your codebase, and every line feels like a step into the abyss. You question your life choices and wonder why you didn't become a chef instead. But then, as you unravel one issue, two more pop up like hydra heads. The sense of despair is palpable.
But, my fellow developers, there's a silver lining in this chaotic journey. The moment when you finally squash that bug is an unparalleled triumph. It's the victory music after a challenging boss fight, the "Eureka!" moment that echoes through the office, and the affirmation that, yes, you can tame this unruly beast we call code.
So, the next time you find yourself knee-deep in debugging hell, remember that you're not alone. We've all been there, and we've all emerged stronger, wiser, and maybe just a little crazier. Debugging is our odyssey, and every error is a dragon to be slain. Embrace the chaos, and may your code be ever bug-free!1 -
What the fuck my friend was telling me about a "awesome" website he found called codecadamy, as a developer I dunno what made him think I did not know how coding works, as I can already do it quite well, but I signed up non the less out of curiosity, immediately I am greeted with a "exclusive" premium offer, and after clicking away from it I find that litterly 90% of the courses are premium only, like wtf? I understand they need to make money, but at that point why make a free Version? I try one of the basics of web development ones, and find it so fucking full of bugs and paywalls that I can not focus on the actual coding. Sense I was fluent in the basic stuff (<h1>hello world</h1> I copied it, and it let me by, after more copying I FOUND A FUCKING BUG IN THERE CODE. I am 99% sure that all the success storys are fake, because the whole think is just one big paywall and inefficient tutorials that I think will only benefit people without knowledge of how to do Google search.8
-
Critical Tips to Learn Programming Faster Sample:
Be comfortable with basics
The mistake which many aspiring students make is to start in a rush and skip the basics of programming and its fundamentals. They tend to start from the comparatively advanced topics.
This tends to work in many sectors and fields of Technology, but in the world of programming, having a deep knowledge of the basic principles of coding and programming is a must. If you are taking a class through a tutor and you feel that they are going too fast for your understanding, you need to be firm and clear and tell them to go slowly, so that you can also be on the same page like everyone else
Most often than not, many people tend to struggle when they reach a higher level with a feeling of getting lost, then they feel the need to fall back and go through basics, which is time-consuming. Learning basics well is the key to be fast and accurate in programming.
Practice to code by hand.
This may sound strange to some of you. Why write a code by hand when the actual work is supposed to be done on a computer? There are some reasons for this.
One reason being, when you were to be called for an interview for a programming job, the technical evaluation will include a hand-coding round to assess your programming skills. It makes sense as experts have researched and found that coding by hand is the best way to learn how to program.
Be brave and fiddle with codes
Most of us try to stick to the line of instructions given to us by our seniors, but it is extremely important to think out of the box and fiddle around with codes. That way, you will learn how the results get altered with the changes in the code.
Don't be over-ambitious and change the whole code. It takes experience to reach that level. This will give you enormous confidence in your skillset
Reach out for guidance
Seeking help from professionals is never looked down upon. Your fellow mates will likely not feel a hitch while sharing their knowledge with you. They also have been in your position at some point in their career and help will be forthcoming.
You may need professional help in understanding the program, bugs in the program and how to debug it. Sometimes other people can identify the bug instantly, which may have escaped your attention. Don't be shy and think that they'll make of you. It's always a team effort. Be comfortable around your colleagues.
Don’t Burn-out
You must have seen people burning the midnight oil and not coming to a conclusion, hence being reported by the testing team or the client.
These are common occurrences in the IT Industry. It is really important to conserve energy and take regular breaks while learning or working. It improves concentration and may help you see solutions faster. It's a proven fact that taking a break while working helps with better results and productivity. To be a better programmer, you need to be well rested and have an active mind.
Go Online
It's a common misconception that learning how to program will take a lot of money, which is not true. There are plenty of online college courses designed for beginner students and programmers. Many free courses are also available online to help you become a better programmer. Websites like Udemy and programming hub is beneficial if you want to improve your skills.
There are free courses available for everything from [HTML](https://bitdegree.org/learn/...) to CSS. You can use these free courses to get a piece of good basic knowledge. After cementing your skills, you can go for complex paid courses.
Read Relevant Material
One should never stop acquiring knowledge. This could be an extension of the last point, but it is in a different context. The idea is to boost your knowledge about the domain you're working on.
In real-life situations, the client for which you're writing a program for possesses complete knowledge of their business, how it works, but they don't know how to write a code for some specific program and vice versa.
So, it is crucial to keep yourself updated about the recent trends and advancements. It is beneficial to know about the business for which you're working. Read relevant material online, read books and articles to keep yourself up-to-date.
Never stop practicing
The saying “practice makes perfect” holds no matter what profession you are in. One should never stop practicing, it's a path to success. In programming, it gets even more critical to practice, since your exposure to programming starts with books and courses you take. Real work is done hands-on, you must spend time writing codes by hand and practicing them on your system to get familiar with the interface and workflow.
Search for mock projects online or make your model projects to practice coding and attentively commit to it. Things will start to come in the structure after some time.4