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
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
Search - "regular changes"
-
Oh, man, I just realized I haven't ranted one of my best stories on here!
So, here goes!
A few years back the company I work for was contacted by an older client regarding a new project.
The guy was now pitching to build the website for the Parliament of another country (not gonna name it, NDAs and stuff), and was planning on outsourcing the development, as he had no team and he was only aiming on taking care of the client service/project management side of the project.
Out of principle (and also to preserve our mental integrity), we have purposely avoided working with government bodies of any kind, in any country, but he was a friend of our CEO and pleaded until we singed on board.
Now, the project itself was way bigger than we expected, as the wanted more of an internal CRM, centralized document archive, event management, internal planning, multiple interfaced, role based access restricted monster of an administration interface, complete with regular user website, also packed with all kind of features, dashboards and so on.
Long story short, a lot bigger than what we were expecting based on the initial brief.
The development period was hell. New features were coming in on a weekly basis. Already implemented functionality was constantly being changed or redefined. No requests we ever made about clarifications and/or materials or information were ever answered on time.
They also somehow bullied the guy that brought us the project into also including the data migration from the old website into the new one we were building and we somehow ended up having to extract meaningful, formatted, sanitized content parsing static HTML files and connecting them to download-able files (almost every page in the old website had files available to download) we needed to also include in a sane way.
Now, don't think the files were simple URL paths we can trace to a folder/file path, oh no!!! The links were some form of hash combination that had to be exploded and tested against some king of database relationship tables that only had hashed indexes relating to other tables, that also only had hashed indexes relating to some other tables that kept a database of the website pages HTML file naming. So what we had to do is identify the files based on a combination of hashed indexes and re-hashed HTML file names that in the end would give us a filename for a real file that we had to then search for inside a list of over 20 folders not related to one another.
So we did this. Created a script that processed the hell out of over 10000 HTML files, database entries and files and re-indexed and re-named all this shit into a meaningful database of sane data and well organized files.
So, with this we were nearing the finish line for the project, which by now exceeded the estimated time by over to times.
We test everything, retest it all again for good measure, pack everything up for deployment, simulate on a staging environment, give the final client access to the staging version, get them to accept that all requirements are met, finish writing the documentation for the codebase, write detailed deployment procedure, include some automation and testing tools also for good measure, recommend production setup, hardware specs, software versions, server side optimization like caching, load balancing and all that we could think would ever be useful, all with more documentation and instructions.
As the project was built on PHP/MySQL (as requested), we recommended a Linux environment for production. Oh, I forgot to tell you that over the development period they kept asking us to also include steps for Windows procedures along with our regular documentation. Was a bit strange, but we added it in there just so we can finish and close the damn project.
So, we send them all the above and go get drunk as fuck in celebration of getting rid of them once and for all...
Next day: hung over, I get to the office, open my laptop and see on new email. I only had the one new mail, so I open it to see what it's about.
Lo and behold! The fuckers over in the other country that called themselves "IT guys", and were the ones making all the changes and additions to our requirements, were not capable enough to follow step by step instructions in order to deploy the project on their servers!!!
[Continues in the comments]26 -
I'm at my seat during the regular morning routine of checking emails, planning the things I need to complete/study when my phone rings.
HR: Good Morning, can you come over to the conference room please ?
Me: Sure
I enter the conference room and on the other side of the table, I see a group of 3 HR Managers (not a very nice feeling), especially when it was 10 months into my first job as a Trainee Software Developer.
HR: The company hasn't been performing as expected. For this reason, we've been told to cut down our staff. We're sorry but we have to let you go. You've been doing a great job all along. Thank you.
Me: ---- (seriously ?!)
The security-in-chief 'escorts' me out of the premises and I hand over the badge. I'm not allowed to return to my desk.
This happened about 16 years ago. But it stuck with me throughout my programming career.
A couple of Lessons Learnt which may help some of the developers today :
- You're not as important as you think, no matter what you do and how well you do it.
- Working hard is one thing, working smart is another. You'll understand the difference when your appraisals comes around each year.
- Focus on your work but always keep an eye on your company's health.
- Be patient with your Manager; if you're having a rough time, its likely he/she is suffering more.
- Programming solo is great fun. However it takes other skills that are not so interesting, to earn a living.
- You may think the Clients sounds stupid, talks silly and demands the stars; ever wonder what they think about you.
- When faced with a tough problem, try to 'fix' the Client first, then look for a solution.
- If you hate making code changes, don't curse the Client or your Manager - we coders collectively created a world of infinite possibilities. No point blaming them.
- Sharing your ideas matter.
- Software Development is a really long chain of ever-growing links that you may grok rather late in your career. But its still worth all the effort if you enjoy it.
I like to think of programming as a pursuit that combines mathematical precision and artistic randomness to create some pretty amazing stuff.
Thanks for reading.14 -
- My client on regular day.
U can manage your tasks by your own. App looks stable and you are doing well.
- Same client when I'm on Vacation
This thing is not working, that thing is not working. This is do or die situation for us. you have to cancel your vacation plans.
- Same client after I come back from vacation in which I wasted precious hours of my vacation time and fixed all the bugs.
I didn't release your changes yet coz I wanted to release it together with you. I was like "THEN WHY THE FUCK YOU RUINED MY VACATION" -_-4 -
TL;DR :
"when i die i want my group project members to lower me into my grave so they can let me down one last time"
STORY TIME
Last year in College, I had two simultaneous projects. Both were semester long projects. One was for a database class an another was for a software engineering class.
As you can guess, the focus of the projects was very different. Databases we made some desktop networked chat application with a user login system and what not in Java. SE we made an app store with an approval system and admin panels and ratings and reviews and all that jazz in Meteor.js.
The DB project we had 4 total people and one of them was someone we'll call Frank. Frank was also in my SE project group. Frank disappeared for several weeks. Not in class, didn't contact us, and at one point the professors didn't know much either. As soon as we noticed it would be an issue, we talked to the professors. Just keeping them in the loop will save you a lot of trouble down the road. I'm assuming there was some medical or family emergency because the professors were very understanding with him once he started coming back to class and they had a chance to talk.
Lesson 1: If you have that guy that doesn't show up or communicate, don't be a jerk to them and communicate with your professor. Also, don't stop trying to contact the rogue partner. Maybe they'll come around sometime.
It sucked to lose 25% of our team for a project, but Frank appreciated that we didn't totally ignore him and throw him under the bus to the point that the last day of class he came up to me and said, "hey, open your book bag and bring it next to mine." He then threw a LARGE bottle of booze in there as a thank you.
Lesson 2: Treat humans as humans. Things go wrong and understanding that will get you a lot farther with people than trying to make them feel terrible about something that may have been out of their control.
Our DB project went really well. We got an A, we demoed, it worked, it was cool. The biggest problem is I was the only person that had taken a networking class so I ended up doing a large portion of the work. I wish I had taken other people's skills into account when we were deciding on a project. Especially because the only requirement was that it needed to have a minimum of 5 tables and we had to use some SQL language (aka, we couldn't use no-SQL).
The SE project had Frank and a music major who wanted to minor in CS (and then 3 other regular CS students aside from me). This assignment was make an app store using any technology you want. But, you had to use agile sprints. So we had weekly meetings with the "customer" (the TA), who would change requirements on us to keep us on our toes and tell us what they wanted done as a priority for the next meeting. Seriously, just like real life. It was so much fun trying to stay ahead of that.
So we met up and tried to decided what to use. One kid said Java because we all had it for school. The big issue is trying to make a Java web app is a pain in the ass. Seriously, there are so many better things to use. Other teams decided to use Django because they all wanted to learn Python. I suggested why not use something with a nice package system to minimize duplicating work that had already been done and tested by someone. Kid 1 didn't like that because he said in the real world you have to make your own software and not use packages. Little did he know that I had worked in SE for a few years already and knew damn well that every good project has code from somewhere else that has already solved a problem you're facing. We went with Java the first week. It failed miserably. Nobody could get the server set up on their computers. Using VCS with it required you to keep the repo outside of the where you wrote code and copy and paste changes in there. It was just a huge flop so everyone else voted to change.
Lesson 3: Be flexible. Be open to learning new things. Don't be afraid to try something new. It'll make you a better developer in the long run.
So we ended up using Meteor. Why? We all figured we could pick up javascript super easy.Two of us already knew it. And the real time thing would make for some cool effects when an app got a approved or a comment was made. We got to work and the one kid was still pissed. I just checked the repo and the only thing he committed was fixing the spelling of on word in the readme.
We sat down one day and worked for 4 straight hours. We finished the whole project in that time. While other teams were figuring out how to layout their homepage, we had a working user system and admin page and everything. Our TA was trying to throw us for loops by asking for crazy things and we still came through. We had tests that ran along side the application as you used it. It was friggin cool.
Lesson 4: If possible, pick the right tool for the job. Not the tool you know. Everything in CS has a purpose. If you use it for its purpose, you will save days off of a project.1 -
Other PM: We must fix the database performance issues now.
Me: We can't. We're still only halfway on the dependency chain to tackle this and honestly, even if the dependency chain would be fulfilled, I'd leave at least 2 weeks monitoring the production after the changes were rolled out before we further poke around.
Other PM: This is taking far too long. And whaddya mean by dependency chain? Why was I not informed about this?
Me: *sigh* like in every meeting in the last weeks: the dependency chain are the current open blockers before we can proceed with the database changes. We've talked about this _at length_... Especially why these blockers exist.
Other PM: No, we need to start now. I've _examined_ at the blockers or "dependency chain" as you call it.
(Examined.... He opened on his currently streaming laptop, which was connected to the active beamer, the mentioned ticket with a detailed blocker ... And quickly scrolled. Yeeah. Warmonger...).
Me: I'm very tired of discussing this. But since you are already presenting us the ticket, read out the referenced meeting notes... We explained it in great detail.
Other PM: Why? This is just a waste of time!!!!!!!
--
Yes. This happened. Other PM was my nemesis.
In this meeting were 2 PMs (Him, Me)… I think 5 - 7 devs... And we were sitting in this meeting since 2 hours at least. Everyone was angry...
After this "manifesto of intelligence"… I simply left the room, followed by a few devs.
And yes. Other PM did this on a regular basis....5 -
It's 5 AM and I don't want to shit on anybody's party but trust me when I say most of you here complaining about legacy code don't know the meaning of the word.
As someone who maintained a PHP4 codebase with an average file length of 3000+ lines for almost 4 years, I feel you, I feel your pain and your helplessness. But I've seen it all and I've done it all and unless you've witnessed your IDE struggle to highlight the syntax, unless you had to make regular changes in a test-less SVN's working copy that **is** the production and unless you are the reason that working copy exists because you've had enough of `new_2_old_final_newest.php` naming scheme, you do not know legacy. If you still don't believe me bare in mind I said "is" as in: "this system is still in production".
But also bare hope. Because as much grief as it cost me and countless before me, today of all days, without a warning, it got green lit for userbase migration to a newer platform. And if this 20 years of generous custom features and per client implemented services can be shut down even though it brings more profit than all the other products combined, so can happen to any of your projects. 🙏
Unfortunately, I do mean *any*.7 -
Our CEO had a virtual town hall using Zoom and now have a sign language interpreter box as a regular feature... To go along with all the Inclusion stuff...
The most immediate problem though is they didn't turn on auto-captions...
I don't know sign but am deaf so needed the captions which it turns out you can get using the Google Recorder app on Pixels. (This is literally like a fuck you to non-Pixel users and Zoom which disables Live Captions in conferences and recording full transcripts).
Anyway I left it own and near the end, a speaker was like "we're getting a lot of likes and positive feedback about the interpreter box! See how small changes make such a big difference?!"
And well of course in my mind I'm going "uh.... No."
I'll just go back to not caring about anything that isn't related to how much I make.2 -
We use jira at my company. It's great for me, because no ticketing system's UI is worth a shit, but jira's API is excellent. But we're switching to a new system that is an absolute piece of garbage. Every page is 100% Javascript, so no source can ever be viewed, and the URL never changes to reflect what's onscreen. If you know a ticket number, no URL will ever get you straight to it. You have to navigate multiple slow-loading 25MB piles of Javascript to reach what you're seeking. And most damning of all: the new system has an API, but our highest management is withholding access to it, claiming it breeds laziness.
Is amazing the kind of shit you have to swallow when your management has regular meetings with really really super extremely good-looking sales people.10 -
Elasticsearch, from the bottom of my heart...
How can one ecosystem be so batshit crazy inconsistent?
Seemingly every agent does the same (e.g. filebeat vs journalbeat vs packetbeat)… yet there are subtle changes in configuration everywhere.
Plus YML. The most shitty markup language one can use and the cockslubbing durps used it fucking everywhere.
Makes fun to have complex stuff and requiring a python Jinja to JSON to YML converter to be able to write the complex stuff without having the fucking migraine to count like a stupid 4 year old whitespace with both hands...
To make it even more absurd: the ingest pipelines which contain a lot of regular expressions / grok and are thus very prone to quoting issues... Yes. Let's do this in YML too.
If you need to add an fucking manual section how to debug YML errors you should have realized what a fucking stupid idea it was, morons.
Now I have the joy of having a python script regex quoting the shit for a Jinja template which then generates JSON which then generates YML.
Why the JSON part?
Yeah... Because ECS and changes in the upstream YML files / GitHub.
To be able to run diffs in a sane way because in YML distinguishing thing is pretty much impossible, so JSON as an intermediary format solely for the purpose of converting upstream YML to JSON to diff it against modified JSON ingest pipelines downstream.
I fucking hate elasticsearch8 -
Since my first post was a success, here's another shameless hack-- in this case, ripping a "closed" database I don't usually have access to and making a copy in MySQL for productivity purposes. That was at a former job as an IT guy at a hardware store, think Lowes/Rona.
We had an old SCO Unix server hosting Informix SQL (curious, anyone here touched iSQL?), which has terminal only forms for the users to handle data, and has keybindings that are strangely vi based (ESC does commit changes. Mindfsck for the users!). To add new price changes to our products, this results to a lengthy procedure inside a terminal form (with ascii borders!) with a few required fields, which makes this rather long. Sadly, only I and a colleague had access to price changes.
Introducing a manager who asks a price change for a brand- not a single product, but the whole product line of a brand we sell. Oh and, those price changes ends later after the weekend (twice the work, back at regular price!)
The usual process is that they send me a price change request Excel document with all the item codes along with the new prices. However, being non technical, those managers write EVERYTHING at hand, cell by cell (code, product name, cost, new price, etc), sometimes just copy pasted from a terminal window
So when the manager asked me to change all those prices, I thought "That's the last time I manually enter all of this sh!t- and so does he". Since I already have a MySQL copy of the items & actual (live) price tables, I wrote a PHP backend to provide a basic API to be consumed to a now VBA enhanced Excel sheet.
This VBA Excel sheet had additional options like calculating a new price based on user provided choices ("Lower price by x $ or x %, but stay above cost by x $ or x %"), so the user could simply write back to back every item codes and the VBA Excel sheet will fetch & display automatically all relevant infos, and calculate a new price if it's a 20% price cut for example.
So when the managers started using that VBA sheet, I had also hidden a button which simply generate all SQL inserts for the prices written in the form, including a "back to regular price" if the user specified an end date, etc.
No more manual form entry for me, no more keyboard pecking for the managers with new prices calculated for them. It was a win/win :)1 -
Restarting regular expression parser from scratch has been good. I am somehow both much farther to completion and farther away from completion than I was in the earlier implementation.
Further in the sense that this implementation is going to be way more flexible to changes in the language
Farther in that I haven’t even got all of the regex parts added to the first stage yet.
But I’m feeing good about it.
Even if I did refactor it so my constants are in all caps and now feel like my core is yelling at me.11 -
So I started to hear a noise on my headphones which I didn't know where it was coming from. It wasn't much of a noise but a regular sequence of "beeps", seemed like 8bit sfx. So I started moving my cable around and it turns out that if I put the headphone's cable under my phone at a specific spot I can hear the noise. Seems like some kind of interference, so the first thing that I thought of is the NFC sensor. So I remembered that an app would detect my credit card (which has NFC) if it was close to the back of my phone, so I put on my headphones and put the cable between the phone and the credit card and voila, the sound changes. It only works if the headphones are be plugged in though.
Idk why but it think this is really cool. Just wanted to share :)2 -
WARNING - a lot of text.
I am open for questions and discussions :)
I am not an education program specialist and I can't decide what's best for everyone. It is hard process of managing the prigram which is going through a lot of instances.
Computer Science.
Speaking about schools: regular schools does not prepare computer scientists. I have a lot of thoughts abouth whether we need or do NOT need such amount of knowledge in some subjects, but that's completely different story. Back to cs.
The main problem is that IT sphere evolves exceedingly fast (compared to others) and education system adaptation is honestly too slow.
SC studies in schools needs to be reformed almost every year to accept updates and corrections, but education system in most countries does not support that, thats the main problem. In basic course, which is for everyone I'd suggest to tell about brief computer usage, like office, OS basics, etc. But not only MS stuff... Linux is no more that nerdy stuff from 90', it's evolved and ready to use OS for everyone. So basic OS tour, like wtf is MAC, Linux (you can show Ubuntu/Mint, etc - the easy stuff) would be great... Also, show students cloud technologies. Like, you have an option to do *that* in your browser! And, yeah, classy stuff like what's USB and what's MB/GB and other basic stuff.. not digging into it for 6 months, but just brief overview wuth some useful info... Everyone had seen a PC by the time they are studying cs anyway.. and somewhere at the end we can introduce programming, what you can do with it and maybe hello world in whatever language, but no more.. 'cause it's still class for everyone, no need to explain stars there.
For last years, where shit's getting serious, like where you can choose: study cs or not - there we can teach programming. In my country it's 2 years. It's possible to cover OOP principles of +/- modern language (Java or C++ is not bad too, maybe even GO, whatever, that's not me who will decide it. Point that it's not from 70') + VCS + sime real world app like simplified, but still functional bookstore managing app.
That's about schools.
Speaking about universities - logic isbthe same. It needs to be modern and accept corrections and updates every year. And now it depends on what you're studying there. Are you going to have software engineering diploma or business system analyst...
Generally speaking, for developers - we need more real world scenarios and I guess, some technologies and frameworks. Ofc, theory too, but not that stuff from 1980. Come-on, nowadays nobody specifies 1 functional requirement in several pages and, generally, nobody is writing that specification for 2 years. Product becomes obsolete and it's haven't even started yet.
Everything changes, whether it is how we write specification documents, or literally anything else in IT.
Once more, morale: update CS program yearly, goddammit
How to do it - it's the whole another topic.
Thank you for reading.3 -
Don't you just love it when gitlab's ci pipelines crash for no apparent reason, causing tests which cannot fail to just magically break down, change logging levels to Just about anything and basically PMS for about 3 hours before it decides it needs to restart completely and when you return the same pipeline which you've been trying to fix for the better part of an entire evening, after regular work hours, it. Fucking. Works. With. No. Changes. To. The. Entire. FUCKING. System.
Waste of a day.3 -
I'm still on a regular basis reminded of how I might be wrong despite the absolute certainty in how obviously wrong the other person is.
Lately I've been working on setting up this API with a fairly intricate database integration. One request can lead to multiple db calls if we're not careful, so we have been polishing up the implementation to guard against ddosing ourselves and dealing with thread-unsafe concurrency.
Someone on the team could happily report that they got rid of all async use so there should no longer be threading issues. "You mean it all runs sync now?" "I guess. It works at least".
I'm just internally pulling a surrender cobra. If this was pre-dev me I would have let him and everyone know what a stupidpants he is and that I thought he had some experience in api development. But let's not make an exception to the rule; I might be wrong. I mean I'm not, but let's pretend I could be. Let's pull down the changes and maybe set up a minimal example to demonstrate how this is a bad idea.
Funny story. He got rid of explicit calls to the database entirely. When resolving data, the query is instead constructed virtually and execution is deferred until the last step. Our functions are sync now because they don't call the database, and threading isn't an issue since there's only one call per request context.
Thank god I've learned to keep my mouth shut until I can prove with absolute conclusive certainty that they are wrong. Here's to another day of not making an ass of myself. -
Anti climactic story time (as in there's no promotion in this story):
Sometime ago there were some organizational changes happening in my company that put me in a very tricky place. Theoretically, I was put on a level that was supposed to be an upgrade from my previous level. Practically, it didn't come with any benefits and it was actually a downgrade because anyone who joined the company in the six months before these changes was in the same level as me (who'd been in for roughly 2 years).
It felt really insulting because I was about to be actually promoted. My manager and his manager tried to gaslight me into believing that I'm not at all affected in any way, before giving in and agreeing that a mistake was made. I was promised that next year it'll be corrected and I'll be promoted two levels. Even the HR assured me of that. I knew it was too good to be true but I was too demotivated to find another job.
Fast forward one year. My bosses are all praises for the work I put in. But, no two level promotion. Reason? They tried but couldn't get the management to agree. The boss apologized to me and asked me if I wanted him to try again. What an insolent arse!
Fast forward one more, extremely glum year.
This time I am part of a different team so the team lead is different but the manager is same. The team lead really went all out with showing appreciation for me. He talked for almost an hour(!) about how I exceeded his expectations and went on to claim that his app's release would have been impossible if it weren't for me, the new team member. It was really humbling and satisfying. But what did I get? A limp handshake from the manager with fucking loose change.
Silver lining. At least the manager did away with the 'well wisher, on your side' pretense this time. No mentions of failed promises, just regular empty promises for the future.
Fast forward 3 months.
Still here. Recovering. I am mulling over a much better offer than what my current boss can give me. Thinking about how long it takes before I'm in the dumpster again. I have stopped giving any fucks about anything here. I try to do the minimum required unless it benefits me in some way.
The end.4 -
I am currently weeks apart from releasing my pet project, which I am working on for almost 6 years now. Of course, there were a few stops here and there, but overall I've spent a lot of time and effort on this to make it work. It is far from complete but I am really happy with the results.
Now, since I am not a professional by any means - it is all a hobby for me - I was wondering, that how much my work would cost, if it were to made by professionals. Below the details so you can get a grasp of the thing.
The whole system is for our family business. We are selling parts for an old-timer truck model. The website was pretty much done already, people like it, it only needed some polishing and adding of the new features. But the thing behind it is monstrous (at least for me).
Apart from the custom-made CMS for the website (most of it was done already and didn't need to change), we can handle orders, partners, prices, stocks, overdue partners, pretty much anything a CRM would do.
There is a logic to automatically make orders based on import prices, or give the customer a custom discount based on the price gap of each product. There are products, which can contain other products, and their prices are dynamically changed based on a given formula, once an underlying product price changes. We can send e-mails when an order status changes, and there is also a page, where a user can interact whit their order, like changing the shipping or the delivery address. The system is (or will in the following weeks) also connected to multiple shipping companies' API, so we can order deliveries and print labels directly from our system. The whole thing is a custom made Laravel project by the way. There are countless more features, but I've just spent 2 hours explaining all to my father and was only be able to cover like half of it.
And why it is all custom made, you ask? Well, the business logic is a bit twisted, so it would be hard to operate as a regular web shop, since the availability of the products are uncertain, given the fact that it is a model, which isn't manufactured in 30 years. So, we can't just accept and send orders without confirming. It is also a thing, that people usually don't know what they need to order for their truck, so we have to help them, so they don't waste their money and the precious last pieces of a part unnecessarily.
Sorry for this rather long post, and it might feel like I just want to brag (well, I kinda do), but I am honestly interested in what such a custom product would cost in the market.
Thank you for your time answering.6 -
There are times when I'm too tired I forget what I changed in the code so I write just "regular" in the title and nothing at all in the description even though it's very obvious i refactored large chunks of the code and added new ones... Regular riight
-
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 -
My team is pretty small right now. It's myself and two other guys. One lead, who's been here for five years. A senior who we brought on 2 weeks ago. And me, a regular app dev. The lead put his two weeks in last week and has been trying to brain dump as much as he can onto us.
I've been building a list of prioritization to compensate for when he leaves based on what he was saying was the most important. This list has gotten pretty massive after reviewing most of the processes in place.
I was hired mainly to quell new requests coming in and not to maintain our systems, so that's what I did. I didn't examine our prod code base too closely. I wish I had. It's in a sorry state. I'm pretty sure I have about 2 years of tech debt for a crew of two guys constantly working on it.
I've been trying to prioritize based on what gets the most bug fixes and change requests. These apps will see the biggest changes and will undergo the most maintenance.
Since I'm just a regular app dev it feels weird trying to come up with this and try to prioritize this and come up with a plan. It feels like someone else should have. If it needs done then I guess it needs done. I need to be able to collaborate and work with my co worker and be able to plan for what projects are coming next.
If anyone has any suggestions to tackle tech debt please make them. Or if there's any help for managing priorities in a different manner that may prove helpful I'm open. Honestly, I don't want to tackle this completely blind, it feels like a lot.1