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 - "solve it yourself"
-
As a developer, sometimes you hammer away on some useless solo side project for a few weeks. Maybe a small game, a web interface for your home-built storage server, or an app to turn your living room lights on an off.
I often see these posts and graphs here about motivation, about a desire to conceive perfection. You want to create a self-hosted Spotify clone "but better", or you set out to make the best todo app for iOS ever written.
These rants and memes often highlight how you start with this incredible drive, how your code is perfectly clean when you begin. Then it all oscillates between states of panic and surprise, sweat, tears and euphoria, an end in a disillusioned stare at the tangled mess you created, to gather dust forever in some private repository.
Writing a physics engine from scratch was harder than you expected. You needed a lot of ugly code to get your admin panel working in Safari. Some other shiny idea came along, and you decided to bite, even though you feel a burning guilt about the ever growing pile of unfinished failures.
All I want to say is:
No time was lost.
This is how senior developers are born. You strengthen your brain, the calluses on your mind provide you with perseverance to solve problems. Even if (no, *especially* if) you gave up on your project.
Eventually, giving up is good, it's a sign of wisdom an flexibility to focus on the broader domain again.
One of the things I love about failures is how varied they tend to be, how they force you to start seeing overarching patterns.
You don't notice the things you take back from your failures, they slip back sticking to you, undetected.
You get intuitions for strengths and weaknesses in patterns. Whenever you're matching two sparse ordered indexed lists, there's this corner of your brain lighting up on how to do it efficiently. You realize it's not the ORMs which suck, it's the fundamental object-relational impedance mismatch existing in all languages which causes problems, and you feel your fingers tingling whenever you encounter its effects in the future, ready to dive in ever so slightly deeper.
You notice you can suddenly solve completely abstract data problems using the pathfinding logic from your failed game. You realize you can use vector calculations from your physics engine to compare similarities in psychological behavior. You never understood trigonometry in high school, but while building a a deficient robotic Arduino abomination it suddenly started making sense.
You're building intuitions, continuously. These intuitions are grooves which become deeper each time you encounter fundamental patterns. The more variation in environments and topics you expose yourself to, the more permanent these associations become.
Failure is inconsequential, failure even deserves respect, failure builds intuition about patterns. Every single epiphany about similarity in patterns is an incredible victory.
Please, for the love of code...
Start and fail as many projects as you can.30 -
Hi, I am a Javascript apprentice. Can you help me with my project?
- Sure! What do you need?
Oh, it’s very simple, I just want to make a static webpage that shows a clock with the real time.
- Wait, why static? Why not dynamic?
I don’t know, I guess it’ll be easier.
- Well, maybe, but that’s boring, and if that’s boring you are not going to put in time, and if you’re not going to put in time, it’s going to be harder; so it’s better to start with something harder in order to make it easier.
You know that doesn’t make sense right?
- When you learn Javascript you’ll get it.
Okay, so I want to parse this date first to make the clock be universal for all the regions.
- You’re not going to do that by yourself right? You know what they say, don’t repeat yourself!
But it’s just two lines.
- Don’t reinvent the wheel!
Literally, Javascript has a built in library for t...
- One component per file!
I’m lost.
- It happens, and you’ll get lost managing your files as well. You should use Webpack or Browserify for managing your modules.
Doesn’t Javascript include that already?
- Yes, but some people still have previous versions of ECMAScript, so it wouldn’t be compatible.
What’s ECMAScript?
- Javascript
Why is it called ECMAScript then?
- It’s called both ways. Anyways, after you install Webpack to manage your modules, you still need a module and dependency manager, such as bower, or node package manager or yarn.
What does that have to do with my page?
- So you can install AngularJS.
What’s AngularJS?
- A Javascript framework that allows you to do complex stuff easily, such as two way data binding!
Oh, that’s great, so if I modify one sentence on a part of the page, it will automatically refresh the other part of the page which is related to the first one and viceversa?
- Exactly! Except two way data binding is not recommended, since you don’t want child components to edit the parent components of your app.
Then why make two way data binding in the first place?
- It’s backed up by Google. You just don’t get it do you?
I have installed AngularJS now, but it seems I have to redefine something called a... directive?
- AngularJS is old now, you should start using Angular, aka Angular 2.
But it’s the same name... wtf! Only 3 minutes have passed since we started talking, how are they in Angular 2 already?
- You mean 3.
2.
- 3.
4?
- 5.
6?
- Exactly.
Okay, I now know Angular 6.0, and use a component based architecture using only a one way data binding, I have read and started using the Design Patterns already described to solve my problem without reinventing the wheel using libraries such as lodash and D3 for a world map visualization of my clock as well as moment to parse the dates correctly. I also used ECMAScript 6 with Babel to secure backwards compatibility.
- That’s good.
Really?
- Yes, except you didn’t concatenate your html into templates that can be under a super Javascript file which can, then, be concatenated along all your Javascript files and finally be minimized in order to reduce latency. And automate all that process using Gulp while testing every single unit of your code using Jasmine or protractor or just the Angular built in unit tester.
I did.
- But did you use TypeScript?37 -
If all you have is a hammer, everything looks like a nail!
This was something which my tech lead used to tell me when I was so obsessed with nosql databases a few years back. I would try to find problems to solve that has a use case for nosql databases or even try to convince me(I didn’t realise it back then) that I need to use nosql db for this new idea that I have, without really thinking deep enough whether the data in question is better represented using an sql schema or not.
Now, leading a team of young developers, I come across similar suggestions from few of my team members who just discovered this new and shiny tech and want to use it in production projects.
While I am not against new and shiny, it’s not a good practice to jump right in to it without exploring it deep enough or considering all the shortcomings. The most important question to ask is, whether some of the problems you are trying to solve can be solved with the current stack.
Modifying your stack requires more than just a week’s experience of playing around with the getting started guide and stack overflow replies. This is something which need to be carefully considered after taking inputs from the people who would be supporting it, that include operations, sysadmins and teams that are gonna interface with your stack indirectly.
I am not talking about delaying adoption by waiting for long list of approvals to get some thing that would bring immediate value, but a carefully orchestrated plan for why and how to migrate to a new stack.
Just because one of the tech giants made a move to a new stack and wrote about it in their engineering blog doesn’t mean that you need to make a switch in the same direction. Take a moment to analyse the possible reasons that motivated them to do it, ask yourself if your organisation is struggling with the exact same problems, observe how others facing the same issue are addressing it, and then make an informed decision.
Collect enough data to support your proposal.
Ask yourself again if you are the one holding the hammer.
If the answer is no, forge ahead!9 -
Please don't make junior developers feel they're a burden.
Have you ever googled "how to mentor junior developers"? It's quite mind-blowing how many articles, talks and panels are on this topic. And yet still junior developers are not feeling welcomed in their companies.
Yup, you guessed it, we also have something to add (based on our own experience):
1. Asking for help is not easy. Please don't blow juniors off by telling them to read docs when they ask a question. Always assume they've read it and did a sprint to solve the problem. They ask you, because they see you as a mentor and really need your help. If you can, spend more time with them and guide through the entire problem solving process.
2. Please don't think "I learnt it this way so you should too". If you're in charge of teaching a junior developer, don't expect them to be a carbon copy of yourself. Because even though in your opinion your approach is more "pro", they might not be there yet to use it properly. And last, but not least:
3. Of course, juniors will compare themselves with seniors on their team. And there'll be moments they feel so guilty and so afraid that they cost the company too much, that they need training, and supervision, or are between projects and are not bringing in any money, and they'll fear that their company regrets hiring them. Make sure they don't feel like a burden. As juniors, we often
have this misconception what is expected from us.
Dear tech companies, please set very clear expectations and tell your juniors you're happy. Don't get us wrong here. We don't expect unicorns, roses and pats on the back from companies. We do understand- this is business, and at the end of the day we all are here to make money. To do so, companies need to make smart investments. Junior dev with a great assistance, planned support, and a clear training program will become a great asset. It really is as simple as that.12 -
To all young freelancers in low-income countries: I want to share my experience, of 6 years working for a piss-poor country, and 6 years working in freelance, and then emigrating. Here's what you should watch out for, and what to expect:
My first salary was barely 1.5$ per hour. I lived in a piss-poor country that taught me a lot (like why it's piss-poor).
The main thing to note when you're a developer in such a country, is that you're being fucked. Your employer might scream at you and tell you how bad you are, while barely paying you. That is you ... being ... fucked. Gain some confidence with the help of friends and family, and a great effort from yourself, look at what freelance gigs you can find, and ditch anything related to jobs in your country.
Being a somewhat able developer, but with modest experience, I started my freelance gigs for 5$ per hour. Because I was lazy, and freelance gigs weren't exactly being thrown at me, I was making 100$ per week, AFTER the companies I worked for appreciated what I did and offered themselves to up my pay to 12$ per hour. Yep. I was lazy. You will likely get lazy in freelance too, so be prepared for this.
My luck changed when one of my clients became a full-time employer, at 15$ per hour, with a well organized team where I actually worked for 40 hours per week (I had already amassed 8 years of experience...). For people in first world countries that will seem laughable, but in my country I was king of the hill, getting paid more than government CEOs that ended up in the news as the "most well paid".
That was the top of the pyramid for international indie freelance, as I would later find out.
I didn't do stuff that was very difficult. In fact, I felt like my abilities were rotting while I worked there. I had to change something. So I started looking for better offers. I contacted many companies that were looking for a senior developer, and the interviews went well, and all was fine, except for my salary demands. I was asking for 25$ per hour. Nobody was willing to pay more than 15$ per hour. That's because of my competition - tons of developers in cheap-to-live countries that had the same, or more to offer, for the same rates. Globalization.
So I moved to Germany. As soon as I was legally able to work, I was hunted down by everybody. I was told that it takes a month to pass the whole hiring process in Germany. My experience demonstrated that 2-5 days is enough to get a signed contract with "Please start ASAP".
There is freelance in Germany as well. And in the US. And everywhere else. A "special" kind of freelance, where you have to reside locally. The rates that this freelance goes for is much, much higher than international freelance. I'd say that 100€ per hour is ok-ish. Some people (newbies, or foreigners who don't speak the language well) get less, around 60 or so. Smart experienced locals get around 150-200 or even more.
It's all there. Companies want good developers to solve their business problems with IT solutions, and they'll beg you to take their money if you can deliver that.
So code!
Learn!
Accummulate experience!
Screw the scumbags that screw you for 1-2$ per hour!
Anyone able to write something more than "Hello World!" deserves more.
Do the climb! There's literally room for everybody up there! There is so much to do, that I feel like there will never be too many developers.
Thank you for bearing with my long story. I hope it will help you make it shorter and more pleasant for you.12 -
1. You don't code to add a feature or whatever. You do it to solve Users' problems. It's a User-centric system.
2. You read more code than you write. So help yourself and write code intended to be read.
3. If people don't know you did something, you did nothing!
4. Never answer a call at 3 am if you're not paid to be on night call-duty. You'll become the guy who answers at 3 am.
5. Remember the big difference between you and me is that I failed to do stuff more times than you have tried to do.
6. When you start shaving the yak, stop!10 -
At an interview, the first round was an online coding round. Two questions, one easy one hard, 90 minutes, easy peasy.
I solved the hard one first.
A bit of good logic, followed MVC pattern, all done. Worked flawlessly.
Submitted code. Online compiler threw up an internal error citing java is an invalid command(jdk not found).
Called the invigilators. What I heard next, I couldn't believe this shit.
"We're not responsible for any errors you may be having. Figure it out yourself"
I was like WTF dude. This is not even a compilation or runtime error!
After a heated discussion, I made him look at the code.
Him - what is all this classes and all? Why haven't you written everything inside the main function?
Me - those are model classes. Those are different helper functions. That is a recursive function to avoid 5 for loops and use divide and conquer. Ever heard of OOP? what kind of person writes a 300 line program inside one function?
Him - no no we write it like that only. Correct this.
Me - I fit everything inside the main function. Still the same error, java not installed. Called the idiot to have a look at it.
Him - yeah your code is wrong.
Me - may I know what's wrong with it? Can you fix it please?
Him - no no we aren't allowed to see the code (he had already read it twice. It was compiling and running perfectly, locally) .
Yeah you solved only 1 problem, you were supposed to solve 2.
Me - yes because the rest of the time I had the pleasure of your company. (It isn't everyday that I see talking buffoons.)11 -
From my work -as an IT consultant in one of the big 4- I can now show you my masterpiece
INSIGHTS FROM THE DAILY LIFE OF A FUNCTIONAL ANALIST IN A BIG 4 -I'M NOT A FUNCTIONAL ANALYST BUT THAT'S WHAT THEY DO-
- 10:30, enter the office. By contract you should be there at 9:00 but nobody gives a shit
- First task of the day: prepare the power point for the client. DURATION: 15 minutes to actually make the powerpoint, 45 minutes to search all the possible synonyms of RESILIENCE BIG DATA AGILE INTELLIGENT AUTOMATION MACHINE LEARNING SHIT PISS CUM, 1 hour to actually present the document.
- 12:30: Sniff the powder left by the chalks on the blackboards. Duration: 30 minutes, that's a lot of chalk you need to snort.
13:00, LUNCH TIME. You get back to work not one minute sooner than 15.00
- 15:00, conference with the HR. You need to carefully analyze the quantity and quality of the farts emitted in the office for 2 hours at least
- 17:00 conference call, a project you were assigned to half a day ago has a server down.
The client sent two managers, three senior Java developers, the CEO, 5 employees -they know logs and mails from the last 5 months line by line-, 4 lawyers and a beheading teacher from ISIS.
On your side there are 3 external ucraininans for the maintenance, successors of the 3 (already dead) developers who put the process in place 4 years ago according to God knows which specifications. They don't understand a word of what is being said.
Then there's the assistant of the assistant of a manager from another project that has nothing to do with this one, a feces officer, a sys admin who is going to watch porn for the whole conference call and won't listen a word, two interns to make up a number and look like you're prepared. Current objective: survive. Duration: 2 hours and a half.
- 19:30, snort some more chalk for half an hour, preparing for the mail in which you explain the associate partner how because of the aforementioned conference call we're going to lose a maintenance contract worth 20 grands per month (and a law proceeding worth a number of dollars you can't even read) and you have no idea how could this happen
- 20:00, timesheet! Compile the weekly report, write what you did and how long did it take for each task. You are allowed to compile 8 hours per day, you worked at least 11 but nobody gives a shit. Duration: 30 minutes
- 20:30, update your consultant! Training course, "tasting cum and presenting its organoleptic properties to a client". Bearing with your job: none at all. Duration: 90 minutes, then there's half an hour of evaluating test where you'll copy the answers from a sheet given to you by a colleague who left 6 months ago.
- 22:30, CHANCE CARD! You have a new mail from the HR: you asked for a refund for a 3$ sandwich, but the receipt isn't there and they realized it with a 9 months delay. You need to find that wicked piece of paper. DURATION: 30 minutes. The receipt most likely doesn't even exist anymore and will be taken directly from your next salary.
- 23:00 you receive a message on Teams. It's the intern. It's very late but you're online and have to answer. There's an exception on a process which have been running for 6 years with no problems and nobody ever touches. The intern doesn't know what to do, but you wrote the specifications for the thing, 6 years ago, and everything MUST run tonight. You are not a technician and have no fucking clue about anyhing at all. 30 minutes to make sure it's something on our side and not on the client side, and in all that the intern is as useful as a confetto to wipe your ass. Once you're sure it's something on our side you need to search for the senior dev who received the maintenance of the project, call him and solve the problem.
It turns out a file in a shared folder nobody ever touches was unreachable 'cause one of your libraries left it open during the last run and Excel shown a warning modal while opening it; your project didn't like this last thing one bit. It takes 90 minutes to find the root of the problem, you solve it by rebooting one of your machines. It's 01:00.
You shower, watch yourself on the mirror and search for the line where your forehead ends and your hair starts. It got a little bit back from yesterday; the change can't be seen with the naked eye but you know it's there.
You cry yourself to sleep. Tomorrow is another day, but it's going to be exactly like today.8 -
There are 3 types of questions.
Type 1 is a question that can easily be answered and mostly appears as the first result in Google.
Type 2 is a question that can be answered by stitching together various type 1 answers.
Type 3 is a question that has not been answered. It may be a bug you’ll have to find out about by reading an email chain 12 years ago or maybe a reason why epoll() doesn’t work on Linux VMs. There is no solid yes or no. You’ve most likely encountered this when reaching page 3 of your Google results and every link is purple (visited).
This is where depression and isolation hits. This is where you realize that if you can’t help yourself, no one else can (or has the experience and time to do so). This is where you must rely on your knowledge and infer an answer to your question pushing your concepts and theories to the extreme. If you solve this question, you’re solving it for someone else who may trek the same path later in the future. You’re solving it for the world!
If you’re willing to solve, attempting to solve, or even giving a reasonable inference about a type 3, you have a true engineering mindset.4 -
Why computers are like men:
In order to get their attention, you have to turn them on.
They have a lot of data, but are still clueless.
They are supposed to help you solve problems, but half the time they are the problem.
As soon as you commit to one, you realize that if you had waited a little longer, you could have had a better model.
Why computers are like women:
No one but the Creator understands their internal logic.
The native language they use to communicate with other computers is incomprehensible to everyone else.
Even your smallest mistakes are stored in long-term memory for later retrieval.
As soon as you make a commitment to one, you find yourself spending half your paycheck on accessories for it.7 -
Man I really hate it when people think that coding doesn't take any concentration and can just interrupt you while you're thinking about how to solve problems
So the other day I was working on how to solve a problem with filtering data with JS, and I had to urgently update one of our pages on our website. I had to update that page according to the content of a Word file, which I didn't check how long it was.
About 15 minutes later everything was ready and published, so I set myself back to my problem.
I get an email from her, "you mixed up things" and she showed up in my office. "There are four pages in this word doc and you copied wrong parts", I was like "ok, I'll fix it". Fixed it two minutes later, went back to code.
Received another email, with another subject, again with another problem. Start getting pissed off for being interrupted for nonsense. Fixed it instantly and put my manager in the email loop so she is aware my other colleague pisses me off.
And again, another direct email "can you fix this?!". I started ignoring her requests because I need some work to be done, and I already lost 2 hours. Got again interrupted by her personal visit to point me which things are wrong, repeating everything twice as I am stupid to her. Man I can't code in peace. I fixed her shit, exactly as she wants and decided to pay my manager a visit to tell her I'm really pissed about being interrupted all the time.
Five minutes before the end of the day, she comes panicking in the office about ANOTHER WORTHLESS issue. Told her it's nothing and went away.
Day is over, thought it was over - a whole afternoon spent correcting her fucking page that gets 10 visits a year.
On the next morning, "there is something wrong with your form, can you check it?!!?" with an attached screenshot. FFFFFFFFUUUUUUUUU STOP ANNOYING ME WITH YOUR FUCKING SHIT CANT WORK ANYMORE. PUT YOUR FUCKING PAGE RIGHT UP YOUR ASS AND FIX IT YOURSELF.
She doesn't have any access to the back end.
Guess I'll have to fix it then...9 -
Suddenly it hits me.
It’s 01:20 here but i get it.
It’s ALL a budget thing.
No dedicated tester means less expenses.
No personal parkspot?
No expenses!
And no good staging or testing environment? Less expenses!
Meanwhile every developer can setup, work on, and maintain about 20 websites on their shitty local Windows machine, that doesn’t even have a proper SSD installed, and we are setting impossible deadlines to figure out who will sink and who will swim.
Ow, here is a SSD.. Figure out the installation yourself because we have no IT knowledge or budget for people that do.
You want a challenge? How about 40 other people that are distracting you all day long.
Meanwhile everybody has to improve their skills in js, react, html5, ccs3, angular, .net and razor so money can made faster.
It would be nice if you could build apps as well.
You had a question? Sorry, no time. Expect some feedback 14 days later.
You finished the site?
Great!
But here are 101 bugs to solve before next week.
All hail their crazy company!2 -
Every 20 minutes, the newcome colleague asks me a question to which he can get an answer by reading the language's tutorial.10
-
Was explaining a technical concept at a "family" dinner. Suddenly stepmother wanted my help for something technical.
Stepmother: Say Awlex, could you help me install some software I recently bought?
Me: (Not this shit again) I even don't know what software you're talking about. How is the software called, what does it do?
Sm: it's calles digital... *long pause*
Me: (I don't like where this is going)
Sm: software... *another long pause*
Me: (fuck me harder than that lightly clothed woman outside)
Sm: something... *long pause*
Me: (alright brain, which way out of here doesn't involves me creating a bullet hole in either one of us?)
Sm: And you can use it to sell something...
Me: (tf do you event sell?!)
Sm: but not like ebay
Me: (what is it then? A platform for selling services? I don't even know what kind of software you'd have to install, given that most of these platforms are be web applications, whcih makes sense for selling stuff on the internet)
Sm: Anyway, could you help me install it? It would take me hours to get into it.
Me: (You think just installing would solve it? As soon as I install it, you probably expect me to be your walking manual as well, don't you?) Look, I'm gonna be honest with you, since I started working I don't have nearly as much free time as I used to have (Not everybody works when they feel like it, you know that?) I get home at around almost 7pm (most of the time) and don't really wanna work afterwards. Most of the time there's a support service from the people who made this software and they would be glad to help you. (Sorry support team, for pushing this bundle of incompetence onto you, but I guess she didn't even listen to my advice).
After that she didn't back down and still wanted my help. Then my grandmother derailed the conversation and got me out of this. When I thanked her later she yold me that she saw I saw uncomfortable and wanted to help. I love my grandmother.
So I am not going to be your "family" tech support. You b(r)ought this onto yourself. Are more than twice my age and still can't use your brain to solve problems like these on your own and you can even less reason abiut your motives and desires when asking for help. I am sick of you and shutty opinions about people, just because I work as a software engineer doesn't mean I'm exist solely for satisfying your unreasonable desires.
Stop offending me and my profession and get yourself some common sense.
Protip #0: Give me one fucking reason to help you, because you're not family enough and your personality really doesn't bring forth any emotion but annoyance4 -
1. Trust no one even yourself
2. Ask questions even if they are stupid
3. Test your solutions, even manually
4. Write comments
5. Take your time to solve problem, even if it looks like easy see point 1
6. Take some time during work to get familiar with code and read something about technology that is part of your current work - even if you know it - see point 1
7. Always try to see a big picture - see point 2 - why is it implemented is more important then how is it implemented2 -
➡️You Are Not A Software Developer⬅️
When I became a developer, I thought that my job is to write software. When my customer had a problem, I was ready to write software that solves that problem. I was taught to write software.
But what customers need is not software. They need a solution to their problem. Your job is to find the most cost-effective solution, what software often is not.
According to the universal law of software development, more code leads to more bugs:
e = mc²
Or
errors = (more code)²
The number of bugs grows with the amount of code. You have to prioritize, reproduce and fix bugs.
The more code you write, the more your team and the team after it has to maintain. Even if you split the system into micro services, the complexity remains.
Writing well-tested, clean code takes a lot of time. When you’re writing code, other important work is idle. The work that prevents your company from becoming rich.
A for-profit company wants to make money and reduce expenses. Then the company hires you to solve problems that prevent it from becoming rich. Confused by your job title, you take their money and turn it into expensive software.
But business has nothing to do about software. Even software business is not about software. Business is about making money.
Your job is to understand how the company is making money, help make more money and reduce expenses. Once you know that, you will become the most valuable asset in the company.
Stop viewing yourself as a software developer. You are a money maker.
Think about how to save and make money for your customers.
Find the most annoying problem and fix it:
▶️Is adding a new feature too costly? Solve the problem manually.
▶️Is testing slow? Become a tester.
▶️Is hiring not going well? Speak at a meetup and advertise your company.
▶️Is your team not productive enough? Bring them coffee.
Your job title doesn’t matter. Ego doesn’t matter either.
Titles and roles are distracting us from what matters to our customers – money.💸
You are a money maker. Thinking as a money maker can help choose the next skill for development. For example:
Serverless: pay only for resources you consume, spend less time on capacity planning = 💰
Machine Learning: get rid of manual decision-making = 💰
TDD: shorter feedback cycle, fewer bugs = 💰
Soft Skills: inspire teammates, so they are more productive and happy = 💰
If you don’t know what to learn next — answer a simple question:
What skills can help my company make more money and reduce expenses?
Very unlikely it’s another web framework written in JavaScript.
Article by Eduards Sizovs
Sizovs.net18 -
I'M TIRED OF HEARING THAT DEVELOPMENT IS NOT A CREATIVE FIELD! Creativity is emerging new ideas from non-existent ones. It is not confined to pretty designs or well-written copy. Sure, devs are logical problem solvers – but not a single dev will solve those problems the same way. Code is like the paint on our dark-themed canvases and you can see yourself out if you think devs are just robotic coding machines8
-
The moment when you can look back at all the comments you wrote to yourself well over a year ago that go along the lines of:
"Don't delete this!"
"I know this looks weird, but trust me!"
"You coded this drunk, you couldn't remember how, and you wrote this comment to remind you that you couldn't understand it sober."
Can all be brushed away, along with the kinda hairy code when you realise that in your attempt to ensure you didn't break code that worked and wasted time trying to understand that you didn't have the experience to solve it, you now have the experience to solve it.
I guess I had such huberis that I assumed I'd never understand a certain problem...1 -
Why computers are like men:
1. In order to get their attention, you have to turn them on.
2. They have a lot of data, but are still clueless.
3. They are supposed to help you solve problems, but half the time they are the problem.
4. As soon as you commit to one, you realize that if you had waited a little longer, you could have had a better model.
Why computers are like women:
1. No one but the Creator understands their internal logic.
2. The native language they use to communicate with other computers is incomprehensible to everyone else.
3. Even your smallest mistakes are stored in long-term memory for later retrieval.
4. As soon as you make a commitment to one, you find yourself spending half your paycheck on accessories for it.1 -
Let me share a piece of advice to entry level devs that are getting ready for job interviews that I wish someone gave to me when I was first looking for work straight out of school. Do not focus making yourself look good to this company by trying to make your resume flashy or trying to oversell yourself. Although its important to present yourself sure, but it should not be the foundation for you to base your interview goals around. Rather focus on the company itself. Find out whether the company itself uses modern technology,practices and upholds to project management and the software development cycle, find out how they work,communicate and develop as a team. Simply put focus on whether they are worth working for instead of looking like your worth being hired. Can they collaborate,communicate and solve problems efficiently. Otherwise you may end up getting hired and hating your job. Just a thought and some advice on my own experiences. Hope it helps someone.3
-
Do these NPC devs even read the README of a project before spewing some dumbass stackoverflow like garbage in an issue thread?
Do your damn job. Being a good software engineer is not like TiKtOk or cHaTgPt where some "magical" answer or entertainment is spoon fed to you, do your absolute best to solve it yourself first, before causing more chaos out in the opensource world.3 -
I've been a part of this industry for over two decades, found myself scraping and clawing my way up, recently leaving a high paying position to create my own company; in an attempt to fix the things I feel are severely broken within the ones I've worked for in the past.
Sometimes, we are challenged in ways we never thought we would be. And, it should always result in the improvement of something we never thought would be possible to improve.
There's a certain beauty of hitting a personal impasse. Because it allows you to choose a better path for yourself - which is a key element in accepting and conquering any one of life's many challenges.
So, just remember, we are - by nature - problem solvers. So what the fuck would we do, without a problem to solve?5 -
Was forced to do some work on Windows this week (CAD tools that runs only on Windows). I spent a few days just setting up the tools. There were quite a few things I realized I forgot about Windows (as compared to Linux).
1) Installation times are down right horrific. What exactly are the installer doing for 10 minutes?
2) .NET is a cluster fuck. Not even Microsofts repair tool can fix it, but rather just hangs. I ended up using another tool to nuke it and reinstall.
3) Windows binary installs are insanely huge, thus, takes forever to download.
4) The registry is a pointless database that must have been written in hell with the single intent of destroying users will to live. The sole existence of the registry is another proof that completely incompetent engineers designed Windows.
5) Rebooting is the only way to solve many problems. This is another sure sign of a fundamentally fucked up OS design.
6) What the heck is wrong with the GUIs designers? The control panel must be the worst design ever. There are so many levels to get to a particular setting I'm getting dizzy. Nothing gets better by the illogical organisation.
7) Windows networking. A perversion of the tcp/ip stack that makes it virtually impossible to understand a damn thing about the current network configuration. There are at least 3 different places that effects the settings.
8) Windows command prompt. Why did they even bother to leave it in? The interpreter is as intelligent as retarded donut. You can't do anything with it, except typing "exit" and Google for another solution.
8) Updates. Why does it takes hundreds of updates per month to keep that thing safe?
9) Despite all updates that is flying out of Redmond like confetti, it is still necessary to install antivirus to keep the damn thing safe. That cost extra money, and further cost you by degrading performance of your hardware.
10) Window performance. Software runs like it was swimming in molasses. The final stab in the back on your hardware investment, and pretty much sends performance on your hardware back a few hundred bucks more.
11) Closed source is evil. If something crash consistently, you might find a forum that address the issues you have. Otherwise you're out of luck. On the other hand, it might be for the better. I imagine reading the code for Windows can lead to severe depression.
I'm lucky to be a Linux dev, and should probably not complain too much... But really, Windows, go get yourself hit by a truck and die. I won't miss you.14 -
Client : We want to develop this particular software. While developing it, we will be following Agile methodology.
Developers: Sure.
After developer achieves few features and decides to give 1st Demo of the software to the client.
Client : Wtf is this? This is an incomplete software, there are bugs in it.
Developer : Yes, you point that out to me and I will solve them.
Client: What do you mean point them out for you l, couldn't you do it yourself?
Developer: As a standard method, we often do unit tests, but we are not testers and with a strict deadline to match, we are more on the core implementation then checking again and again for minor bugs.
Client : I thought it would be a full proof software without any bugs in the 1st demo.
Developer : Software development is a process. It's not straightforward, hence you only mentioned at the initial, it's agile.
Client : If that's so, let's make it not agile and make you rot in hell for the next few fays. Now you next time show me a demo with no bugs, great complicated features and we will not mention you our expectations, predict them by yourselves, and most importantly, here's an impractical strict deadline.4 -
Ask yourself a couple of simple questions:
Do you like to code?
Do you like to learn new things and improve?
Do you like to solve problems and spend hours on a single detail until it finally works?
If your answers contain a "no", then development is probably not for you. You will hate it and you will suck at it. And you will make lifes of devs who actually love it miserable. So do something else.6 -
The worst part of being a dev
My social dilemma
In a fast paced world where the average human spends at least 6 hours a day with technology, deriving basic entertainment, pleasures and engaging in various activities.
Here we are the developers that have to engage with technology for longer hours for a living , having to keep up with deadlines, immersing our minds in complicated algorithms and then the endless possibilities of entertainment from the machine in so few human hours a day , you wonder how you’d get off, and to top it up, I personally work from home.
And then the dilemma of overcoming different suggestions from various parties in taking a break off, a break off to what you later ask yourself, thus creating the shadow of doubt, splitting the fragile programmer’s mind , trying to solve this imaginary puzzle, “this bug of the mind”.
Then the challenge often arises in creating a balance, telling yourself, just catching up with people with this same technology takes a whole day, or then again quitting my Job, but from my little experience of life, nobody likes a poor visitor, this is actually worse than a “bug” and as I bask in this quagmire, “a little voice in my head keeps singing keep doing what you love doing”.
Like an infinite loop of crazy, spiralling back to these machines, trying the find and fix the balance of normalcy. Always remembered the cool years of college tho, with so much people around and then again that was college.
An then the thought arises, maybe something else might be worth doing, but after so much time spent in building your skills and the enormous joy of programming even typing without looking at the keyboard is a real pleasure, and yeah sure the days are short with the reality of a constant need to survive, remain sane, compete and make the best of life in such short time.
Then how do we know if we have fallen off the so-called “social track”, when we have only lived so little to really comprehend the most parts of life? with such constant stream of unanswered question, you’d realise you shouldn’t have burdened the mind creating such questions in the first place
But then again maybe it gets better, one of the above, the disturbed mind or the situation as whole and yes I try oh I try, I place calls, do some visiting, no relationship tho but with a good perspective in mind.
In this race of life, you sometimes ask yourself would you rather be in a different position, or maybe already put exactly where we belong. For this illusionary fight with self is a fight with reality as a whole and true bliss comes from actually letting go as time and people pass you by.
And my greatest achievement to date aside family and my work is getting into the 1000 club on devRant.2 -
Whoever it was that thought that MAC address spoofing/randomization for "muh network security" was a good idea, I'm gonna violently fucking murder them. It doesn't solve jack shit for security, doesn't magically make your network device "anonymous" or whatever and it never fails to confuse my DHCP servers that use those fucking things. Whoever it was, hang yourself or I'll fucking do it for you. Filthy incompetent motherfucker!!13
-
Wish everyone on stackoverflow followed this etiquette:
1. Don't be lazy, before you post try and solve the issue yourself and check that your post isn't a duplicate.
2.Make sure that you post is coherent and specific.
3. If someone helps you acknowledge it.5 -
What were some of your "OH MY GOD I'M AN AWESOME CODE WIZARD!" moments?
For example, I can remember two or three:
One was when I, with only cursory knowledge of C, never having worked with it but having been exposed to it (and having lots of experience with C# therefore familiar with the c-family syntax), took 5 minute look at a source code and pointed out a bug that the student working on it was trying to solve for the past 2 hours. Sadly, I don't remember what the bug was anymore.
Second one was on reddit, someone posted to gamedev group a 2minute video from his voxel+ai framework he was working on, I watched it, and without any idea what it's written in, or how, I was like "you seem to be dropping frames in a pretty regular manner unrelated to anything I see happening on the screen. You're creating too much garbage on frame-by-frame basis (probably while your AI is exploring what to do), look into object pooling, it'll help".
And the guy responded in a few hours like "by gosh, you're right! thank you! and what do you think about the source code?" (he linked git repo below the video.
And I was like OMG I'M A MAGE, I DIDN'T EVEN CLICK THE REPO LINK, ONLY NOW AFTERWARDS, AND yeah, it's c++ so sadly nothing for me, but OMG I JUST WROTE THE FIRST THING THAT CAME TO MY MIND, DIDN'T EXPECT IT TO BE CORRECT, I'M AWESOME.
=D and the feeling stayed with me for about two days.
(If it's not clear yet, it's perfectly okay, in fact, required, to brag about yourself in answering this question ;) )18 -
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 -
!rant // deprecated but who cares
I just wanted to write down something i realized. I realized that that I stopped growing as an individual a while ago.
Being a student put me in constant stress situations. I had to do things quickly. Lern things fast, drop things I don't understand immediately, move on, and repeat. I think this corrupted me, turning learning into something that it's not supposed to be. Even making me reject other people's opinions sometimes, which disgusts me every time I think back to it.
When I started programming I'd always try to read the code, until i completely understood what exactly this code was doing. Something I stopped doing a while ago because of the mentioned time constraints.
But today I got the hit by the consequences (German: Ich hab Retourkutsche abbekommen)
I was implementing an algorithm today, while my partner was writing the main program, which acted as indirect test cases. And the errors were discovered one after another because of my misinterpretation. Or Simply put, my lack of knowledge. Because it was already late, we stopped soon afterwards but I wanted to solve this problem by tomorrow. I really wanted to get my head around this algorithm, so that i could solve it with confidence. After getting my head smoking I felt something I haven't in a while: the feeling of achieving something. Making me finally realize not only how the algorithm was actually meant to work but it also made me again realize what learning is about.
Use your damn head.
Don't look away from the problem, solve it! Learning is about challenging yourself!
Sorry for stealing away so much of your time. Like i said, i just wanted to write this down. Maybe to burn this into my mind, to keep me on the right track from now on. But I also hope that i could deliver my message to someone that needed it as well.
Also it's late and i should have gone to sleep long time ago. 😴😵
I just hope my grammar didn't suffer because I'd that -
Kinde messed up my first contract.
I am a senior frontend dev who until now worked only on full time gigs. For the first time I picked up a short term gig of 1 week that consisted of 2 packages and I wanted to share my mistake that I made so hopefuly its useful to you.
So last week I started working on this gig. First package went through fine, I delivered in 2 days and collected the first half of the payment.
However I messed up with the second package. Not messed up the implementation per say, but I didnt manage the communication well.
Before implementing it I raised a discussion about a missing backend endpoint that is required to implement the perfect solution. Client got cold feet, had a discussion with his manager and now decided to postpone the second package and even got mad at me that I already did and pushed half of the work of the second package without waiting for his decision from his manager. So now obviously Im not getting paid for half of the work of the second package (I dont mind, I should have waited for clients response), anyways it took me like 20min to implement so thats fine.
My takeaways:
1. As a short term contractor you are hired to solve a concrete problem. Scope out what you can, agree on a task list and stick to it. Anything out of scope will cost the client extra.
2. Your priority is to get paid. Not to deliver the perfect solution that confuses the client and potentially can impact your delivery. If he wants something and you see its only a half of what he really needs, deliver it anyways. Keep that idea of improvement for the future. More work for future = more invoices = more money. I know its not ethical but your priority should be to get paid and in order to do that you need to deliver. Dont shoot yourself in the foot with unnecesseraly overcomplicating things.1 -
Time spent getting to grips with your OS is usually time spent well. While you're not operations, it really helps being able to solve general problems yourself without calling support.
Oh, and: Set up a good bashrc, and put it on the servers you're working with.4 -
Helpdesk: We can't figure out our own ambigious error message, you should solve it in another way...
Me: I see in the console that I get an execption response with an ID, you must be logging these exceptions, can't you check those?
Me thinking: you've just reduced yourself to desk without the help part -
has it ever happens to you that for whole day you kill yourself to solve error and next day you find out it was just happening because of a single semicolon
it hurts...3 -
Our teacher who teaches us Linux doesn't even know how to run shell script. Every time we ran into the problem he is like you should solve by it yourself. Most of his lectures seems nonsense to me and looks like I'm wasting my time and money7
-
No no no. That's it. Less than 2 years experience supposed to be leading a team of 12 soon to be 17 most of which have more experience than me! Been given sever admin responsibilities, training and managing 2 large frame works in addition to everything else I was doing before.
With the current set of projects we were given half the amount of time to do over twice the amount of work. Management seems to expect constant over time. And I keep being nagged by management to finish x,y,z. Every thing is high piority and I keep being asked to switch between tasks every hour or so nothing gets completed when this happens every time I make them aware this happens. The worse thing is that the CEO has a way of naming and shaming people who fall behind work infront of the entire company.
I have only been surviving thanks to a few saints in the team who just get on with the work without argument but now found out a bunch of these are moving to better companies!!!
I like helping people but with everything that is going on I can't find time to and I know at times I end up coming across inpatient with them that they don't deserve. But if you are part of a team please try and solve your issue yourself before asking others every half an hour there are too many of you and I need to get things done too.
And why is it so damn hot sitting at the desk sweating.
Ok I am prob on my meriod and being over the top grumpy. I want to find a new job but so tired in the evenings that I just want to collapse on my bed and do nothing. At end of writing this and feel a little better.2 -
So I have this PO who is able to understand technicalities. He is also able to use postman and has access to our code - don't ask why. He is trying stuff out with our apis, looking through code to understand parts of the software, etc.
So there are two sides of having a PO who is able to understand us devs on a certain level:
On the one hand you can explain why story x is taking longer than expected. You can even discuss in a proper way, which is nice. On the other hand is he a bit over the top: when we plan stories he already analysed everything, put code into the story and is telling us how to solve an issue or implement a story.
The sad part is that none of my colleagues seem to be bothered by the fact that he is doing my work.
And recently i even heard a sentence like: "I do not understand why this story should have 3Sp. Would be way lower when I do it". Well.. then do it yourself freaking idiot.
That goes so far that he tells other teams how to fix their code when there is an issue, because he has access to the code and can (unfortunately) read it..
Very unpleasant. :/ So: do you guys have/had the same issues? Am I overreacting?3 -
go fuck yourself with your fucking communities. i went into computing because i like being left alone. who are all those fucking freaks building their communities? this is capitalism mother fuckers, everybody in the world agreed on it, on each person being an independent individual doing their job to the best possible standard, instead these low-skill low-iq oversocialised sheeple started conglomerate into communities and brainwash everybody that this is what it is about. get stuffed alright. all my life i've been introverted, just leave me alone to write code alright? take my library i don't mind i'll take yours no strings attached, just push the code and forget about it. but no, all these degenerate morons without CS degrees have occupied our safe space, pushed us out of it and just can't get enough of using the buzzword "community-driven" "volunteers" volunteer my ass assholes you can't even make software nobody in real industry needs you because you have no skill at all you learn a bit of js which is any 14-15 yo can do and now think you're some kind of prodigies, unsung heros of humanity who selflessly bring the progress. nothing can be further from the truth - because of you we don't have real software, we don't have investment we don't get no respect everybody walks all over software engineers treating us like shit, there's an entire generation of indoctrinated parasitic scum that believes that software tools is grown for them on trees by some development teams that their are entitled to automatically, because some corporation will eventually support those big projects - yeah does it really happen though - look at svelte, the guy is getting 50k a year when he should be earning at least 500k if he had balls to start a real businesses, but no we are all fucking prostitutes, just slaving away for the army of people we never see. are you out of your mind. this shit should be fucking illegal alright it's modern day slavery innit bruh, if a company wants to pay their engineers to work on open source this is fine, i love open source like java or google closure compiler, but it's real software made by real engineers, but who are all these community freaks who can't spend a 10 seconds on stage in their shitty bogus conferences without ringing the "community" buzzer? you're not my community i fucking hate your guts you're all such dumb womenless imbeciles who justify their lack of social skill by telling themselves that you're doing good by doing open source in your free time - mate nobody gives a shit alrite? don't you want money sex power? you've destroyed everything that was good about good olde open source when it was actually fun, today young people are coerced into slavery at industrial scale, it's literally impossible to make a buck from software as indie unless you build something really big and good, and you can't build anything big without investment and who invests in software nowadays? all the ai "entrepreneurs" are getting fucking golden rained with cash while i have to ask for a 5$ donation? what the actual fuck? who sanctions this? the entire industry is in one collective psychotic delusion, spurred by microsoft who use this army of useful idiots to eliminate all hounour dignity of the profession, drive the abundance and bring about poverty of mind, character, as well as wallet as the natural state of things. fucking amatures of course you love your shitty little communities because you can't achieve anything on your own. you literally have no personality, just one homogenous blob of dumb degenerates who think and act all the same. there used to be a tool called adobe flash builder, i could just buy it, then open and make a web app, all from start to finish in one program, using tutorials of adobe experts on youtube, sure it might have had its pitfals but it was a product - today there's literally no fucking product to make websites. do you people get it? i can't buy a tool that i need to do my job and have to insult myself by downloading some shitty scripts from some shitty unemployed devs and hope my computer doesn't blow up in my face in the process because some freak went off his nut and uploaded some dodgy ass exploit on npm in his package. i really don't like. it's not supposed to be like that. good for me i build by own front/back end. this "community" insanity is just a symptom of industrial degeneration, they try to sell it to us like it's the "bright" communist future but things never been worst, i can't give a shit about functional programming alright i just need to get my job done mate leave me alone you add functional because you don't know how to solve the problem properly, e.g., again adobe flex had mxml where elements had ids and i could just program to id, it was alright but today all this unqualified morons filled the whole space after flash blew up and adobe execs axed flash builder instead of adapting it to js runtime, it was a crime against humanity that set us back to 1000s5
-
Tabs, or No Tabs? I did the same as this commentor 2 years ago. I can code so quick now because of this simple switch. Here's why:
(source, Laracasts.com)
Ben Smith
"I think the most beneficial tip was to do away with tabs. Although it took a while to get used to and on many occasions in the first few days I almost switched them back on, it has done wonders for my workflow.
I find it keeps my brain more engaged with the task at hand due to keeping the editor (and my mind) clutter free. Before when I had to refer to a class, I would have opened it in a new tab and then I might have left it open to make it easier to get to again. This would quickly result in a bar full of tabs and navigation around the editor would become slow and my brain would get bogged down keeping track of what was open and which tab it was in. With the removal of the tab bar I'm now able to keep only the key information in my mind and with the ability to quickly switch between recently opened files, I find I haven't lost any of the speed which I initially thought I might.
In fact this is something I have noticed in all areas of writing code, the more proficient I have become with an editor the better the code I have been writing. Any time spent actually writing your code is time in which your brain is disconnected from the problem you are trying to solve. The quicker you are able to implement your ideas in code, the smaller the disconnect becomes. For example, I have recently been learning how to do unit testing and to do so I have been rewriting an old project with tests included. The ability to so quickly refactor has meant that whereas before I might have taken 30 seconds shuffling code around, now I can spend maybe 5 seconds allowing my mind to focus much better on how best to refactor, not on the actual process of doing so."
jeff_way Mod
"Yeah - it takes a little while to get used to the idea of having no tabs. But, I wouldn't go back at this point. It's all about forcing yourself into a faster workflow. If you keep the tabs and the sidebar open, you won't use the keyboard."2 -
I love learning by doing.
Building MVPs and prototypes is the best way. Even better if you have a chance to show and share them in front of an audience (peer pressure can be good!).
Share the lessons you've learned and what you've done wrong, it will help many more people than just yourself.
I've been working for an eLearning company for the last 4 years (CloudAcademy.com) and I'm in love with the idea of learning something new every day. And not just coding. Code is "only" a tool to solve problems, and learning something about those problems and fields will make you a better developer. -
Apparently, a lot of people here are complaining about the fact cs classes (and I'm talking about uni here) are way too much theory and far too less teaching practical things. And don't get me wrong, I don't like viewing cs only from a theoretic point of view either, BUT I think cs education is made to teach you how solve complex cs problems by yourself and give you the tools on how to learn about these things in the future. And this is very much theory.
CS is the science part, so don't wonder if there's a lot of theory in it. If you only want to learn how to program, maybe you should take programming courses instead.
In school though, cs education should be less theory and more doing practical (funny) things, programming, "how does the internet work", "why I should not give my credit card details to random strangers on the internet", things like that.2 -
To those of us who suffer from "Not invented here syndrome", I want you to ask yourself this question. If "reinventing the wheel is so valuable", would you re-implement the entire OSI stack?
No, as it would be a COMPLETE waste of time!!!
In all the layers below your application, several things related to how your code gets presented to your end-user are abstracted away from you. If you are able to accept that completely, why do you feel the need to re-implement every well-understood part of your particular project?
Cars, for example, are mostly made from standardized parts that solve well-understood problems. It then may have a few custom parts that may solve some novel problems to make it stand out from the rest.
Buildings are made completely from standardized parts, with regulations on how they are put together with some room for artistic flare.
If Software wants to be as equally respected as the rest, we need to get to that point.
DONT reinvent the wheel, just use battle-tested parts and just focus on what your project is trying to solve. It will be way more fruitful and fulfilling.
/rant6 -
This is more of an essay than a rant. TLDR at the end. I simply can't choose from all the shitty lecturers I've had, so I'm going to have to go through them one by one. But of background. I'm currently in 7th year of college, I did a multimedia degree in 2 years, a intro course to Software Dev and I'm currently in my final year of my Software Dev degree. So let's start.
Intro Software Course
- we had a database module, which was thought by, I shit you not, the head of the psychology course in the college, she attempted to teach us Databases using access. And not even using SQL, using access GUI components and it's query builder. Need I say more?
1st year software dev
- We had a networking module, the guy that taught the labs, he literally didn't say more than 12 words the entire 12 week semester, his answer to any question you asked him was a grunt and "research it"
- We had a psychology module, I have no fucking idea why, but instead of learning something useful we were told to read this and get in touch with your feelings...
- database module. Yes we actually did SQL here, 12 weeks of select statements and normal form, talked about by a guy in a monotone voice, who sounded like he was contemplating bringing in an assault riffle some day. Also instead of using MySQL he decided to use Ingres. Why I will never know.
2nd Year Software Dev
- We had a module called Algorithms and Data Structures. The lecturer gave us problems she couldn't solve. Simple problems. She was also crazy. Absolutely nuts.
- Object Orientated Programming. I had this lecturer for 3 semesters up until 3rd year. This guy did COBOLT in college, graduated in the 70s or something and went straight into teaching, he taught us Java for nearly 2 years. He literally copied and pasted texts from PDFs and read through them in class. He told myself and another guy at one stage he really didn't care, and was just counting down the days to his retirement.
- Databases again, different lecturer from 1st year, taught us for 2 semesters (24 weeks) and somehow managed to teach us nothing.
3rd Year Software Dev
- software engineering.. This is where the biggest cunt I've ever met was introduced. He arrives into class 15 minutes late every time without fail, talks shit about stuff that has no relevancy to the topic at all, tries to turn everything into a rugby metaphor and every time you ask a question he somehow dodges it and swiftly changes topic. This cunts past profession? A Project Manager. Fucking typical. This dickhead has also thought me 2 other modules.
4th yr Software Dev
- El cunto mentioned above for 2 more modules. Need I say more.
- real time systems, this module took the piss, the module was written by the lecturer which is what earns his space here. Assignments given to us, which required more time to do than we had in labs so we had to work at home, the problem we that is we were using an obscure RTOS called OS9 which would only work on the college computers. When brought to the lecturers attention he just said "figure it out"
Internet of Things - There was 2 lecturers, each lecturer seemingly working off a different plan, one week you'd have one lecturer, the next would be the other one going on about something completely different and unrelated to anything else we'd done.
Some lecturers didn't even make this list as I couldn't be bothered trying to think back about how shit other ones were. These were the ones that always stood out in my mind.
My main take away point from this is that you go to college for the paper which says you have a degree. Learning things that are going to benefit you in a career is up to yourself.
TLDR; 90% of my college lectures were shit. You need to learn useful stuff yourself.1 -
I can't help it sounding bitter..
If you work some amount of time in tech it's unavoidable that you automatically pick up skills that help you to deal with a lot of shit. Some stuff you pick up is useful beyond those problems that shouldn't even exist in the first place but lots of things you pick up over time are about fixing or at least somehow dealing or enduring stuff that shouldn't be like that in the first place.
Fine. Let's be honest, it's just reality that this is quite helpful.
But why are there, especially in the frontend, so many devs, that confuse this with progress or actual advancement in their craft. It's not. It's something that's probably useful but you get that for free once you manage to somehow get into the industry. Those skills accumulate over time, no matter what, as long as you manage to somehow constantly keep a job.
But improving in the craft you chose isn't about somehow being able to deal with things despite everything. That's fine but I feel like the huge costs of keeping things going despite some all the atrocities that arose form not even considering there could be anything to improve on as soon as your code runs. If you receive critic in a code review, the first thing coming back is some lame excuse or even a counter attack, when you just should say thank you and if you don't agree at all, maybe you need to invest more time to understand and if there's some critic that's actually not useful or base don wrong assumptions, still keep in mind it's coming from somebody that invested time to read your code gather some thoughts about it and write them down for you review. So be aware of the investment behind every review of your code.
Especially for the frontend getting something to run is a incredibly low bar and not at all where you can tell yourself you did code.
Some hard truth from frontend developer to frontend developer:
Everybody with two months of experience is able to build mostly anything expected on the job. No matter if junior or senior.
So why aren't you looking for ways to find where your code is isn't as good as it could be.
Whatever money you earn on top of your junior colleagues should make you feel obligated to understand that you need to invest time and the necessary humbleness and awareness of your own weaknesses or knowledge gaps.
Looking at code, that compiles, runs and even provides the complete functionality of the user story and still feeling the needs do be stuff you don't know how to do it at the moment.
I feel like we've gotten to a point, where there are so few skilled developer, that have worked at a place that told them certain things matter a lot Whatever makes a Senior a Senior is to a big part about the questions you ask yourself about the code you wrote if if's running without any problems at all.
It's quite easy to implement whatever functionality for everybody across all experience levels but one of your most important responsibilities. Wherever you are considered/payed above junior level, the work that makes you a senior is about learning where you have been wrong looking back at your code matters (like everything).
Sorry but I just didn't finde a way to write this down in a more positive and optimistic manner.
And while it might be easy to think I'm just enjoying to attack (former) colleaues thing that makes me sad the most is that this is not only about us, it's also about the countless juniors, that struggle to get a food in the door.
To me it's not about talent nor do I believe that people wouldn't be able to change.
Sometimes I'm incredibly disappointed in many frontend colleagues. It's not about your skill or anything. It's a matter of having the right attitude.
It's about Looking for things you need to work in (in your code). And investing time while always staying humble enough to learn and iterate on things. It's about looking at you
Ar code and looking for things you didn't solve properly.
Never forget, whenever there's a job listing that's fording those crazy amount of work experience in years, or somebody giving up after repeatedly getting rejected it might also be on the code you write and the attitude that 's keeping you looking for things that show how awesome you are instead of investing work into understanding where you lack certain skills, invest into getting to know about the things you currently don't know yet.
If you, like me, work in a European country and gathered some years of industry experience in your CV you will be payed a good amount of money compared to many hard working professions in other industries. And don't forget, you're also getting payed significantly more than the colleagues that just started at their first job.
No reason to feel guilty but maybe you should feel like forcing yourself to look for whatever aspect of your work is the weakest.
There's so many colleagues, especially in the frontend that just suck while they could be better just by gaining awareness that there code isn't perfect.6 -
The 20 minute rule:
If you are unsure about a problem, you MUST spend 20 minutes trying to solve it yourself. If you havent solved it in those 20 minutes, you MUST ask someone for help.
Never tried this in practice but it sounds decent in theory. 2 heads are usually better than 12 -
So just a normal rant here. .. it was one of those moments you find in yourself in sometimes. You get so caught up in thinking you know everything that you can't implement occams razor into your everyday work routine anymore. You've worked with so many complex workarounds that when you are faced with a simple problem with a simple answer you can't see the blinking neon light shouting at you anymore , and you can't here the bells sound anymore. ..
My rant is about Me vs the infamous mikrotik router. Something I had to set up. Something I had to login to setup. Something I've done so many times before but this time , my inflated ego and overbearing sense of grandeur just could not figure out.
Class how do we login into a router? Well find your gateway and type that sucker into a browser and you will be on your way ... well that's the answer right there. But since I thought that my router was connected to three dummy switches that it would affect anything or the paranoia I had that my isp somehow disabled any connections to the router at all or that I and to open a new port to connect to it or use winbox to connect to it using only the mac address or ssh into it ..would work ...I didn't try using the tried and tested way of doing it.
I wanted it to be an adventure. I wanted it to be a problem to solve so I shoved the ordinary answer out of the way and used other methods to try and connect to it...
All I had to do was used Nmap to scan the gateway for open ports and realise to view it in the Browser on port 8080 instead and finish my journey ...
I was looking for a dragon to slay , a maze to conquer, glory at the end of my mission ... when all I felt was a sheer sense of idiocy.
--Rant Completed-- -
Every once in a while I come across a challenge that's actually challenging. Most recently ... "Develop Regex for validating and extracting a recipe's ingredient's quantity"
Regex should properly identify the numbers in each of the following lines:
1 cup of ingredient
Diced 1/2 cup of ingredient
.5 tsp of ingredient
1 1/2 packed cup of ingredient
1.5 cup of Heavy whipping cream
My answer is the first comment in case you want to solve it yourself. I'd love to know what others come up with.5 -
Could people kindly stop trying to expand upon the native DI in dotnet!
This is my third project where "you don't just" add new services because you have to carefully conform to hundreds of lines of boilerplate while "remembering to" whatever it demands because someone spent weeks hacking the builtin functionality in order to make it easier and shorten the startup file.
I'm trying to swap out one of the implementations that are used by one other class via DI and so far I've changed 12 files. It's literally more work to do the thing DI is designed to solve compared to not using DI because they "improved" upon it.
Sure, it might be that I'm not using your thing correctly, but that's not much better, is it. Everyone already knows how to use dotnet's DI. Literally noone knows how to use your improved version aside from yourself.
I liked how one of the team members put it after one of the former devs apologetically explained how this was some long-gone dev's baby: The only thing this code does for us is that it needs a diaper change every time we deal with it.2 -
I got one task left... One algorithm to solve... That's the second day I'm on it... And I need to sleep so much... Fix yourself please, let me write random lines and please work...1
-
I've been doing pretty well since lockdown (March) and making some projects to spent my time and practicing problems on hackerrank, leetcode, etc.
But now I don't feel like it anymore, another day passes by where I decide to solve or make something but still can't somehow.
my GitHub's contribution shows no activity since 4 weeks, how do you guys keep yourself motivated every day?
coz this lockdown is soo draining. ugh 🤦🏻♂️ -
Well not like friends as such but kinda of get people respect when you are good at it.
It was during 12th Grade while working on our project for the year , everyone had some kind of doubt and you know the Teacher is not always free to help every one so after looking at what me and my friends were creating she said approach them for your doubts.
Well I can be a prick sometime if I want to be mostly because you are writing bad code or your facts are wrong hence not a lot of them used to like , like me.
But after that they had no option hence felt pretty badass after that.
And like not that I was criticizing them but it you don't want to learn then please solve your own doubts yourself.
Maybe I was wrong to you know to teach everyone. but well that's me do it right else don't do it.