Details
-
AboutGraphics Programmer by night, Student by day.
-
SkillsNim, C++, OpenGL
Joined devRant on 8/31/2016
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
-
Call me old-fashioned, but... I kinda liked it back in the day, when Microsoft made proprietary software, the Community made free software and everyone's "cui bono" was quite easy to answer - even those corporations involved in FLOSS did have a clear way to finance themselves.
Now, we have Microsoft coming into open source, seemingly making projects better and offering more and more "free" stuff.
You know.
"Free" Windows 10.
"Free" SaaS Office.
"Free" "Private" Repos on Github.
In general - what happened to clear and concise "I give you money, you give me stuff" capitalism like we had it in the 2000s?
I'd rather pay 20 bucks for a game on Steam than get it "free" and with ads or microtransactions - yet, many games, especially mobile, don't even offer me that option. It wouldn't be that hard now, would it?
The same goes for software. That Canonical would need to fuck their users over after Ubuntu One went to shit was obvious - they didn't offer the kind of commercial/enterprise OS'es that Redhat or SuSE sell.
What people seem to forget is that everyone needs to make a profit somehow. You don't get "free" stuff. Even the volunteers in the Open Source Community get something out of it - an opportunity to pad their CV at least, if nothing else.
Nowadays, software manufacturers have the same legitimacy as the "free" financial "advisors" you find at banks - and who could be dumb enough to trust them? Oh yeah: Almost the entire fucking society is who.
But then again, sell something and noone will want it - because they all want it for free, with annoying, privacy-invading ads or with equally annoying microtransactions, or financing based on commission - so you don't only pay ONCE, you pay until you realize you got fucked over and quit.
Capitalism used to work until all those idiots stepped in. How the fuck don't people realize that there's no free lunch in life? When have we stopped being functional people and turned into idiots.
Even worse: Those idiots think that they're entitled to something! They, who volunteered to become merchandise instead of customers, think that they have rights! Do cattle have rights? Nope. They get their "free" hay everyday and I get to buy beef, that's how it works. Moo!
Hell, they are surprised when they get fucked over by bank salespeople or their data stolen by corporations, intelligence agencies or something... What did they expect, goodwill?
Can we please make Adam Smith mandatory reading in school?! I mean, give people a chance to understand capitalism? The nonexistent "goodwill" of traders in general?8 -
I took a programming class this semester in which a have to write code on paper, and the more I write, the more I agree. I give you my word-
I will ***never--- ever--- write code on paper again***14 -
📍Developers
|
|
| _ _ _ _ _ _ _ _ _ _ _ _ _ _
|
📍 Getting work done |
_ _ _ _ _ _ _ _ _ _ _ _ _ _ |
|
|
|
📍Change and customise the latest Linux distro6 -
Have you ever wondered we programmers have so many strong communities.... Stackoverflow, devRant, Reditt, etc...
No other profession has such communities... Why? Why?
Because, we haven't built one for them.... 😂😁60 -
!rant
After over 20 years as a Software Engineer, Architect, and Manager, I want to pass along some unsolicited advice to junior developers either because I grew through it, or I've had to deal with developers who behaved poorly:
1) Your ego will hurt you FAR more than your junior coding skills. Nobody expects you to be the best early in your career, so don't act like you are.
2) Working independently is a must. It's okay to ask questions, but ask sparingly. Remember, mid and senior level guys need to focus just as much as you do, so before interrupting them, exhaust your resources (Google, Stack Overflow, books, etc..)
3) Working code != good code. You are an author. Write your code so that it can be read. Accept criticism that may seem trivial such as renaming a variable or method. If someone is suggesting it, it's because they didn't know what it did without further investigation.
4) Ask for peer reviews and LISTEN to the critique. Even after 20+ years, I send my code to more junior developers and often get good corrections sent back. (remember the ego thing from tip #1?) Even if they have no critiques for me, sometimes they will see a technique I used and learn from that. Peer reviews are win-win-win.
5) When in doubt, do NOT BS your way out. Refer to someone who knows, or offer to get back to them. Often times, persons other than engineers will take what you said as gospel. If that later turns out to be wrong, a bunch of people will have to get involved to clean up the expectations.
6) Slow down in order to speed up. Always start a task by thinking about the very high level use cases, then slowly work through your logic to achieve that. Rushing to complete, even for senior engineers, usually means less-than-ideal code that somebody will have to maintain.
7) Write documentation, always! Even if your company doesn't take documentation seriously, other engineers will remember how well documented your code is, and they will appreciate you for it/think of you next time that sweet job opens up.
8) Good code is important, but good impressions are better. I have code that is the most embarrassing crap ever still in production to this day. People don't think of me as "that shitty developer who wrote that ugly ass code that one time a decade ago," They think of me as "that developer who was fun to work with and busted his ass." Because of that, I've never been unemployed for more than a day. It's critical to have a good network and good references.
9) Don't shy away from the unknown. It's easy to hope somebody else picks up that task that you don't understand, but you wont learn it if they do. The daunting, unknown tasks are the most rewarding to complete (and trust me, other devs will notice.)
10) Learning is up to you. I can't tell you the number of engineers I passed on hiring because their answer to what they know about PHP7 was: "Nothing. I haven't learned it yet because my current company is still using PHP5." This is YOUR craft. It's not up to your employer to keep you relevant in the job market, it's up to YOU. You don't always need to be a pro at the latest and greatest, but at least read the changelog. Stay abreast of current technology, security threats, etc...
These are just a few quick tips from my experience. Others may chime in with theirs, and some may dispute mine. I wish you all fruitful careers!222 -
I have multiple but one of my biggest ones:
Build an entire suite of services which can replace the popular Google/microsoft/facebook (etc) services.
Of course: privacy respecting, preferrably everything possible end-to-end encrypted.
Because fuck mass surveillance and those companies and if I can do anything to fuck them (quite literally) and help people getting to user friendly alternatives, I'll do the best I can.21 -
Get my hunter license.
Become the pirate king.
An anime adaptation before we are 18.
Liberate Japan from Britannia.
Get Kokonotsu to take over the candy shop.
Kill my teacher before he wipes out humanity.
Kill all the kabane.
Kill all the titans.20 -
Actually finish a proj.... Oh I'm sorry I got distracted and started a new projec... Oh look a bird...1
-
"I was wondering why Monitors sleep and Keyboards don't.
Then it occurred to me that Keyboards have two SHIFTS. 😆😆" -some guy17 -
Three years into studying software engineering and three quarters of my class have no idea what git is.
But by gosh, can we code the shit out of a tic tac toe game.18 -
I had to create a c++ dungeon 2d game as University project.
The spec said "a terminal game made with char"
I and my team made a real game with anemies boss, and balanced stat in 15 days with Qt (we asked if can use external libraries)
We got 6/8 point for the project cuz we forgot to put protected/private the attribute of the player...3 -
That moment that everything seems to be working well enough but you're too afraid to release because of stuff you might have missed 😅4
-
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 -
I cannot find a job because I don't have experience and I cannot get experience because I don't have a job.
-- Ancient Chinese Proverb5