Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple APILearn More
Search - "i prefer more lines"
Still trying to get good.
The requirements are forever shifting, and so do the applied paradigms.
I think the first layer is learning about each paradigm.
You learn 5-10 languages/technologies, get a feeling for procedural/functional/OOP programming. You mess around with some electronics engineering, write a bit of assembly. You write an ugly GTK program, an Android todo app, check how OpenGL works. You learn about relational models, about graph databases, time series storage and key value caches. You learn about networking and protocols. You void the warranty of all the devices in your house at some point. You develop preferences for languages and systems. For certain periods of time, you even become an insufferable fanboy who claims that all databases should be replaced by MongoDB, or all applications should be written in C# -- no exceptions in your mind are possible, because you found the Perfect Thing. Temporarily.
Eventually, you get to the second layer: Instead of being a champion for a single cause, you start to see patterns of applicability.
You might have grown to prefer serverless microservice architectures driven by pub/sub event busses, but realize that some MVC framework is probably more suitable for a 5-employee company. You realize that development is not just about picking the best language and best architecture -- It's about pros and cons for every situation. You start to value consistency over hard rules. You realize that even respected books about computer science can sometimes contain lies -- or represent solutions which are only applicable to "spherical cows in a vacuum".
Then you get to the third layer: Which is about orchestrating migrations between paradigms without creating a bigger mess.
Your company started with a tiny MVC webshop written in PHP. There are now 300 employees and a few million lines of code, the framework more often gets in the way than it helps, the database is terribly strained. Big rewrite? Gradual refactor? Introduce new languages within the company or stick with what people know? Educate people about paradigms which might be more suitable, but which will feel unfamiliar? What leads to a better product, someone who is experienced with PHP, or someone just learning to use Typescript?
All that theoretical knowledge about superior paradigms won't help you now -- No clean slates! You have to build a skyscraper city to replace a swamp village while keeping the economy running, together with builders who have no clue what concrete even looks like. You might think "I'll throw my superior engineering against this, no harm done if it doesn't stick", but 9 out of 10 times that will just end in a mix of concrete rubble, corpses and mud.
I think I'm somewhere between 2 and 3.
I think I have most of the important knowledge about a wide array of languages, technologies and architectures.
I think I know how to come to a conclusion about what to use in which scenario -- most of the time.
But dealing with a giant legacy mess, transforming things into something better, without creating an ugly amalgamation of old and new systems blended together into an even bigger abomination? Nah, I don't think I'm fully there yet.9
"What we can do to get all on time? ", manager asks
"Can we have 4 more developers on the project?", dev asks
"No, that's not gonna happen. Let's be realistic", manager says
"Is it realistic to ask 3 devs to ship 20 features in a week, reviewed and tested?" dev asks
"Actually 2 of you, because our contractor goes into a vacation. But you can do overtimes, can't you?"
"I prefer not to but even in that case I can't guarantee that as it's not realistic. But at least can I leave earlier and work more from home more because there are severe delays on the train lines and if I have to commute 4 hours a day it won't help", dev says
"Well, I'm not sure if that's a good idea. You have to communicate with people, you know. We have to ship things. But we can discuss this tomorrow as I have to leave early today. I have to take my kids from school"
sooooooooo for my current graduate class we were to use the MVC pattern to build an IOS application(they preferred it if we did an IOS application) or if you didn't have an Apple computer: an Android application.
The thing is, they specified to use Java, while in their lectures and demos they made a lot of points for other technologies, hybrid technologies, such as React Cordova, all that shit, they even mentioned React Native and more. But not one single mention of Kotlin. Last time I tried my hand at Android development was way before Kotlin, it was actually my first major development job: Mobile development, for which we used Obj C on the IOS part and well, Java on the Android part.
As some of you might now, I rarely have something bad to say about a tech stack(except for VBA which I despise, but I digress) and I love and use Java at work. But the Android API has always seem unnecessarily complex for my taste, because of that, when I was working as a mobile development I dreaded every single minute in which I had to code for Android, Google had a great way to make people despise Java through their Android API. I am not saying it is shit, I am not saying it is bad, I just-dont-like-it.
Kotlin, proves a superior choice in my humble opinion for Android development, and because the language is for retards, it was fairly easy for me to pick it up in about 2 hours. I was already redesigning some of my largest Spring applications using half the code and implemented about 80% of the application's functionality in less than 3 hours(login, fragment manipulation, permissions, bla bla) and by that time I started to wonder if the app built on Kotlin would be ok. And why not? If they specifically mentioned and demonstrated examples using Swift, then surely Kotlin would be fine no? Between Kotlin and Java it is easy to see that kotlin is more similar to Swift than Java. So I sent an email. Their response: "I am sorry, but we would much rather you stick with the official implementations for Android, which in this case is Java for the development of the application"
I was like 0.o wat? So I replied back sending links and documentation where Google touted Kotlin as the new and preferred way to develop Android applications, not as a second class citizen of the platform, but as THE preferred stack. Same response.
Eventually one of the instructors reflected long enough on it to say that it was fine if I developed the application in Kotlin, but they advised me that since they already had grading criteria for the Java program I had to redo it in Java. It did not took me long really, once I was finished with the Kotlin application I basically rewrote only a couple of things into Java.
The end result? I think that for Android I still greatly prefer Kotlin. Even though I am not the biggest fan of Kotlin for anything else, or as my preferred language in the JVM.
I just.......wish....they would have said something along the lines of: "Nah fam please rewrite that shit for Java since we don't have grading criterias in place for Kotlin, sorry bruh, 10/10 gg tho" instead of them getting into an email battle with me concerning Kotlin being or not being the language to use in Android. It made me feel that they effectively had no clue what they were talking about and as such not really capable of taking care of students on a graduate level program.
Made me feel dirty.12
Have any of you already felt that you really like what you do (coding, of course, among other things), but you hate "the place(s)" where you work, specifically some of the people from there...?!?!?
It's 9AM, you already got your coffee, is comfortably sat, with your precious headphones, all ready for some gorgeous lines of code to gain life... but...
... your coworkers are arguing cos one prefer braces when using an single-line if statement, the other not...
... another one is discussing about how bad he's paid after discovering that a dev (at the same "level") receives more...
... the coordinator comes to convince you that the manager is not good, has not all the needed "certifications", and vice versa ...
... the designer didn't like the UX's work, and this is just an enough reason for a BIG gossip with the rest of the team (or even with people from other teams) ...
... the QA complains all the time about everything: the testing environments are a shit, the other QAs are a shit, the system is a shit, his life is a shit (even though he has not yet realized it) ...
Sometimes I miss that time when I got into the coding universe at home, giving my first steps and was creating things all the time... against the toxicity we find in a lot of enterprise "habitats"...1
This started as an update to my cover story for my Linked In profile, but as I got into a groove writing it, it turned into something more, but I’m not really sure what exactly. It maybe gets a little preachy towards the end so I’m not sure if I want to use it on LI but I figure it might be appreciated here:
In my IT career of nearly 20 years, I have worked on a very wide range of projects. I have worked on everything from mobile apps (both Adroid and iOS) to eCommerce to document management to CMS. I have such a broad technical background that if I am unfamiliar with any technology, there is a very good chance I can pick it up and run with it in a very short timespan.
If you think of the value that team members add to the team as a whole in mathematical terms, you have adders and you have subtractors. I am neither. I am a multiplier. I enjoy coaching, leading and architecture, but I don’t ever want to get out of the code entirely.
For the last 9 years, I have functioned as a technical team lead on a variety of highly successful and highly productive teams. As far as team leads go, I tend to be a bit more hands on. Generally, I manage to actively develop code about 25% of the time to keep my skills sharp and have a clear understanding of my team’s codebase.
Beyond that I also like to review as much of the code coming into the codebase as practical. I do this for 3 reasons. I do this because as a team lead, I am ultimately the one responsible for the quality and stability of the codebase. This also allows me to keep a finger on the pulse of the team, so that I have a better idea of who is struggling and who is outperforming. Finally, I recognize that my way may not necessarily be the best way to do something and I am perfectly willing to admit the same. I have learned just as much if not more by reviewing the work of others than having someone else review my own.
It has been said that if you find a job you love, you’ll never work a day in your life. This describes my relationship with software development perfectly. I have known that I would be writing software in some capacity for a living since I wrote my first “hello world” program in BASIC in the third grade.
I don’t like the term programmer because it has a sense of impersonality to it. I tolerate the title Software Developer, because it’s the industry standard. Personally, I prefer Software Craftsman to any other current vernacular for those that sling code for a living.
All too often is our work compiled into binary form, both literally and figuratively. Our users take for granted the fact that an app “just works”, without thinking about the proper use of layers of abstraction and separation of concerns, Gang of Four design patterns or why an abstract class was used instead of an interface. Take a look at any mediocre app’s review distribution in the App Store. You will inevitably see an inverse bell curve. Lot’s of 4’s and 5’s and lots of (but hopefully not as many) 1’s and not much in the middle. This leads one to believe that even given the subjective nature of a 5 star scale, users still look at things in terms of either “this app works for me” or “this one doesn’t”. It’s all still 1’s and 0’s.
Even as a contributor to many open source projects myself, I’ll be the first to admit that have never sat down and cracked open the Spring Framework to truly appreciate the work that has been poured into it. Yet, when I’m in backend mode, I’m working with Spring nearly every single day.
The moniker Software Craftsman helps to convey the fact that I put my heart and soul into every line of code that I or a member of my team write. An API contract isn’t just well designed or not. Some are better designed than others. Some are better documented than others. Despite the fact that the end result of our work is literally just a bunch of 1’s and 0’s, computer science is not an exact science at all. Anyone who has ever taken 200 lines of Java code and reduced it to less than 50 lines of reactive Kotlin, anyone who has ever hit that Utopia of 100% unit test coverage in a class, or anyone who can actually read that 2-line Perl implementation of the RSA algorithm understands this simple truth. Software development is an art form. I am a Software Craftsman.
today I thought writing a quick project, a youtube proxy server, as in, you browse localhost:<PORT> and youtube comes in the response.
this is not rocket science as proxy servers have around for a long time.
I thought it'd be interesting to code it in userland, as opposed to "systemland".
And 50 lines of code and some minor hurdles later I see youtube "running" in localhost.
Although youtube didn't just work as usual since the videos don't actually come from youtube.com, but from googlevideo.com instead. And my browser, expectably, enforces CORS and forbids any requests to it.
At that point I started to think of ways to somehow proxy googlevideo.com too. But the solutions are not at all trivial.
Then I thought what was the payoff of all this. I tried to proxy serve youtube out of curiosity, and sure thing, you can do it.
But what problem would proxying youtube solve? Maybe I should think in a fuller way what are the problems I have with youtube.
One issue I have is the exposure, discoverability. To explain it, let's say I have been watching a very, very big amount of videos as of today.
Personally I would expect youtube to understand very well by now what my tastes are, what do I want to watch and what I do NOT want to watch.
Notice that I am very black and white, and I do not have much interest in watching certain types of videos.
It could be true that if my expectations of how youtube should work became reality then youtube recommendations would become polarizing or echo chambering.
But that is my decision though, and the problem with youtube is that it's seemingly forcing a single recommendations algorithm onto everyone.
Some people are more open minded and want to watch EVERYTHING, and a lot of people don't.
But users aren't deciding what they should get recommended. Youtube is making that decision for them. And it sure feels like it's trying to maximize ad revenue.
I for one don't give two flying fucks about pranks or diva youtubers. Yet youtube is adamant in presenting some of these to me.
Now, trying to come up with a solution for this is really non trivial. It would definitely require some youtube mining, or some kind of network so as to not get rate limited when mining, and even then you still have to think of how a good recommendation system would work.
I think the implementation of all that would be too much for me (time and skill wise). But I think it's fun to at least try to outline how recommendations could work.
I would very much prefer that when youtube recommended something, at least it has some number of confidence meaning how much would I like that video, so at least I know what to expect.
It should also have some indicators like what is the mood of the video. As in, sometimes I watch youtube in the mood of learning, like programming videos, but most of the time I watch to get entertained.
These ideas are just brainstorms and could be terrible on reproduction, but I'd like to hear what ideas can some of the people here can come up with.2