Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
Search - "focus tool"
-
The university system is fucked.
I've been working in this industry for a few years now, but have been self taught for much longer. I'm only just starting college and I'm already angry.
What does a college degree really mean anymore? From some of the posts I've seen on devRant, it certainly doesn't ensure professional conduct, work ethic, or quality (shout out to the brave souls who deal with the lack of these daily). Companies should hire based on talent, not on a degree. Universities should focus more on real world applications or at least offer such programs for students interested in entering the workforce rather than research positions. A sizable chunk of universities' income (in the U.S. at least) comes from research and corporate sponsorships, and educating students is secondary to that. Nowadays education is treated as a business instead of a tool to create value in the world. That's what I signed up for, anyway - gaining the knowledge to create value in the world. And yet I along with many others feel so restricted, so bogged down with requirements, fees, shitty professors, and shitty university resources. There is so much knowledge out there that can be put to instant practical use - I am constantly shocked at the things left out of my college curriculum (lack of automated tests, version control, inadequate or inaccurate coverage of design patterns and philosophies) - things that are ABSOLUTELY essential to be successful in this career path.
It's wonderful that we eventually find the resources we need, or the motivation to develop essential skills, but it's sad that so many students in university lack proper direction through no fault of their own.
Fuck you, universities, for being so inflexible and consistently failing to serve your basic purpose - one of if not the most important purpose on this earth.
Fuck you, corporations, for hiring and paying based on degree. Fuck you, management, for being so ignorant about the industry you work in.
Fuck you, clients, who treat intelligent people like dirt, make unreasonable demands, pull some really shady shit, and perpetuate a damaging stereotype.
And fuck you to the developer who wrote my company's antipattern-filled, stringy-as-all hell codebase without comments. Just. Fuck you.17 -
Less recruiter and more recruiting company.
Specifially: Robert Half.
t;ldr version:
Robert Half is scammy as hell, and they 'fired' me for quitting when my girlfriend got raped. Really.
------
Robert Half took half of my paychecks for the entire duration of my contracts with them. I didn't know right away because, as a policy, they hide how much the hiring company is paying for you, and they also forbid the company from telling you. (The company pays RHI, RHI pays you). Makes sense why they hide it because it certainly pissed me off.
Long story short, I worked for a php dev shop through them (after telling them to lower their fees or i'd walk), worked there for awhile (while remote moonlighting because why not!), and quit. I quit because my girlfriend at the time had just gotten raped, and with the emotionall fallout from that, there was no way I could focus on two jobs and be there for her. My boss understood and let me leave, though it put him in a bind.
The next day, I got a call from the regional manager of Robert Half. He was a total tool. He demanded to know if I quit, didn't care why I quit, proceeded to "educate" me in the finer points of why that was unprofessional and why i'm unemployable, accused me of lying about idr what, and finally switched into legalese to say "I regret to inform you that you can no longer consider Robert Half as a means of employment." (or something along those lines) and hung up on me. Asshole. I hope various large someones rape him so he has an inkling what it's like to be objectified and thrown away like trash.
Guy was an asshole; probably still is.
RHI was awful and scammy; probably still is, too.
Wasn't really a fan of the job either.
So at the end of it, I wasn't out anything but some patience and serenity (a lot of serenity). I kept the first (remote) job, was there for my girlfriend, and helped her through everything.
But yeah, Robert Half?
They can fucking go to hell.18 -
A decade ago 800x600 was pretty much the standard resolution for devices and 5 sec response time was considered fast. Animations were minimal and websites were easier to read. Programmers debated around topics like which loop runs faster, i++ or ++i, while vs doWhile and so on. In general, we were closer to understanding what happens behind the browser curtain and how code needs to be organized to make it more maintainable.
Today the level of abstraction is much higher. I don't think devs can contemplate on the finer aspects of programming efficiency; they'd rather rely on a code library to do all the grunt work. With the explosion of devices and platforms, the focus has shifted from programming to assembling. Programmers need to know their tools first, then write code. The tool is expected to work well with a millisecond response time, not the programmer's code.
Moving forward, I think programming would be more about building higher abstraction utilities/libraries that are integrated by other tools, which is already happening. Marketing an App would become more important than the actual skill needed to develop it.
A bit far-fetched, but I think the future programmer would be a lot like a stock market analyst who has a bunch of windows in front, just observing data or algorithm patterns created by an AI engine and cherry-picking a specific combination of modules that might make the next big sensational app.8 -
Satoru Iwata.
You might remember it as the former president of Nintendo, but he was also a very impressive programmer. As he was president of HAL Laboratories, he helped with the development of Pokémon Stadium for the Nintendo 64 by porting the Pokémon Red/Blue battle system not by having any sort of documentation, but by reading the assembly source code.
He did so to allow Game Freak's developers (who were only a team of 4 at the time) to focus on their work on Pokémon Gold/Silver. But he did more: when they had to localize Red/Blue for America, they couldn't fit everything in a cartridge. They had the same problem while developing Gold/Silver, since cartridges had at most 8 Mb of storage capacity back then, and they had to fit not only the Johto region but the Kanto one as well! So Iwata stepped in, and created a graphics compression tool which managed to make everything fit in the cartridges.
He did this while not even being part of Nintendo, and the work was so impressive that the Pokémon devs thought it was "a waste to just have [him] as president!" (ie. why not make use of such programming skills).
Truly someone I look up to.8 -
TL;DR :
"when i die i want my group project members to lower me into my grave so they can let me down one last time"
STORY TIME
Last year in College, I had two simultaneous projects. Both were semester long projects. One was for a database class an another was for a software engineering class.
As you can guess, the focus of the projects was very different. Databases we made some desktop networked chat application with a user login system and what not in Java. SE we made an app store with an approval system and admin panels and ratings and reviews and all that jazz in Meteor.js.
The DB project we had 4 total people and one of them was someone we'll call Frank. Frank was also in my SE project group. Frank disappeared for several weeks. Not in class, didn't contact us, and at one point the professors didn't know much either. As soon as we noticed it would be an issue, we talked to the professors. Just keeping them in the loop will save you a lot of trouble down the road. I'm assuming there was some medical or family emergency because the professors were very understanding with him once he started coming back to class and they had a chance to talk.
Lesson 1: If you have that guy that doesn't show up or communicate, don't be a jerk to them and communicate with your professor. Also, don't stop trying to contact the rogue partner. Maybe they'll come around sometime.
It sucked to lose 25% of our team for a project, but Frank appreciated that we didn't totally ignore him and throw him under the bus to the point that the last day of class he came up to me and said, "hey, open your book bag and bring it next to mine." He then threw a LARGE bottle of booze in there as a thank you.
Lesson 2: Treat humans as humans. Things go wrong and understanding that will get you a lot farther with people than trying to make them feel terrible about something that may have been out of their control.
Our DB project went really well. We got an A, we demoed, it worked, it was cool. The biggest problem is I was the only person that had taken a networking class so I ended up doing a large portion of the work. I wish I had taken other people's skills into account when we were deciding on a project. Especially because the only requirement was that it needed to have a minimum of 5 tables and we had to use some SQL language (aka, we couldn't use no-SQL).
The SE project had Frank and a music major who wanted to minor in CS (and then 3 other regular CS students aside from me). This assignment was make an app store using any technology you want. But, you had to use agile sprints. So we had weekly meetings with the "customer" (the TA), who would change requirements on us to keep us on our toes and tell us what they wanted done as a priority for the next meeting. Seriously, just like real life. It was so much fun trying to stay ahead of that.
So we met up and tried to decided what to use. One kid said Java because we all had it for school. The big issue is trying to make a Java web app is a pain in the ass. Seriously, there are so many better things to use. Other teams decided to use Django because they all wanted to learn Python. I suggested why not use something with a nice package system to minimize duplicating work that had already been done and tested by someone. Kid 1 didn't like that because he said in the real world you have to make your own software and not use packages. Little did he know that I had worked in SE for a few years already and knew damn well that every good project has code from somewhere else that has already solved a problem you're facing. We went with Java the first week. It failed miserably. Nobody could get the server set up on their computers. Using VCS with it required you to keep the repo outside of the where you wrote code and copy and paste changes in there. It was just a huge flop so everyone else voted to change.
Lesson 3: Be flexible. Be open to learning new things. Don't be afraid to try something new. It'll make you a better developer in the long run.
So we ended up using Meteor. Why? We all figured we could pick up javascript super easy.Two of us already knew it. And the real time thing would make for some cool effects when an app got a approved or a comment was made. We got to work and the one kid was still pissed. I just checked the repo and the only thing he committed was fixing the spelling of on word in the readme.
We sat down one day and worked for 4 straight hours. We finished the whole project in that time. While other teams were figuring out how to layout their homepage, we had a working user system and admin page and everything. Our TA was trying to throw us for loops by asking for crazy things and we still came through. We had tests that ran along side the application as you used it. It was friggin cool.
Lesson 4: If possible, pick the right tool for the job. Not the tool you know. Everything in CS has a purpose. If you use it for its purpose, you will save days off of a project.1 -
Area of focus: Native iOS dev
Why: Spent years trying hybrid tools, dealing with the most ridiculous errors, bugs and issues you can begin to comprehend and then ... something magical happened. I got a book on Objective-c, learned a little, tried a simple app ... and it worked ... like properly worked, and on all the devices without taking half the RAM.
I'll say that again as I don't think it landed. In Objective-c, I got no issues where only the CEO's phone + OS version meant I couldn't load a map and a pin (looking at you titanium!!!)
In Objective-c, I wasn't promised storyboards and autolayout, only to find out they are completely different, and may god help you trying to google the issues, as the only ones to show up would be the native tools (looking at you Xamarin)
In Objective-c, my app doesn't instantly consume 125mb of RAM to load a fucking webview (looking at you ... well nearly every other hybrid tool)
... it just works. Then Swift came along and things only got better.13 -
Finally getting off my proverbial ass and doing something about the lack of games I like. Going to focus on making an engine for the kind of games I want to play.
No, I am not starting from scratch. Going to base my engine on Godot and use it for my own titles. I am not insane. Making it from scratch is too much work these days. But the indies are shifting from Unity to other engines right now. So a lot of wanted attention will be placed on better alternatives. This means more content and plugin choices will be available to Godot devs.
I kept making excuses as to how hard it will be or it will take forever. It only ended up taking me further away from what I wanted. I have my wishlist of features and I will focus on modularizing them so they can be used as needed. If it makes sense I will make these modules available to the community at Godot. This will help get feedback on what can be improved and generalized further. It will also reduce development costs in the long run. I want to take the approach that No Man's Sky has taken for content and generate as much as I can. I am fascinated by generating objects using algorithms. This seems to be a trend in games.
The struggle I have with games: I want to build things like structures in game (aka Minecraft), I want to build characters in game (aka RPGs), I also want to deform terrain (aka organic voxels), and I want a mixed genre (guns and dragons). Nothing like this exists in a form I want to pay for. I also want to be able to mod the game and for other people to be able to mod the game. That really narrows the list of games down to nothing. Sure there are few games that hit these bullet points, but not all in the same game.
I am finding I struggle to be engaged intellectually at work. I do what I have to for a paycheck. I think having a side project will help with this. One that is radically different than what I do at work is going to be helpful. I need to be realistic about expectations. I probably shouldn't expect any real progress for at least 2 to 3 years and probably more likely 5 years. I have some experience with the tool chains from other engines I have worked with. I also want something that I own and is mine. Even if it sucks.33 -
Todays story: conversation between me and my brain about a app that i have planned for a long while.
The application is just a huge, specyfic json editor/manager for a game that i like. The game uses json files to determine unit charactetistics. So in order to make modding easier i want to make a tool for that that is fancier and easier to use than a notepad.
Brain> Lets make a app that allows you to mod the game easier!
Me> Good idea. How would you want to make it?
Brain> Lets use C# cause you main that lang currently and you have experience with json parser lib.
Me> That is true. So what do you wanna implement first?
Brain> Oh. I have thought about it before! I want to implement: (10 000 features) and maybe few more later!
Me> It sounds like a infinity project, shouldnt you implement like 1 or 2 features at first and then jump to other ones?
Brain> Yes... but i dont wanna refactor those features latter so let just implement them all at once!
Me> Dammit brain! Let just implement just one feature now! Like a simple json editor. You can use inhieritance to reuse the code later.
Brain> Ok...
* Starts with that one feature but one day later starts coding 6 more *
* Cant publish the app yet, the code looks like shit, gui is unfinished because brain wanted only to test those 6 unfinished features without propely implementing them *
Me> Brain WTF! You said that you are going to focus on one feature at the time!
Brain> I got carried a bit...
Me> ...
Me> Ok. I understand. Let just refactor the code and clean the project out of those unfinished features.
Brain> No. I have a depression now...
Me> FUCK.
* 2 month passes by without any progress on ANY of my projects*
current day
Brain> I still have depression...
Me> Ok i dont care about that anymore! Tell me something that i dont know!
Brain> Oh I have good news as well!
Me> ???
Brain> What about the home server that is going to store all mods made by the users so they can share it? It would be a good practice with networking!
Me> * Gives up *1 -
Creating a stripped down version of a product is a big red flag to me (e.g. "easy/light mode").
It means the main product is too complicated; it handles too many things. Instead, shift the focus back to the core of the product by removing features.
In the our day-to-day it is completely normal to stumble upon things that used to work but now have been changed: they have been deprecated.
Deprecating and removing features should be added to any product iteration. Thus being "normal" and a common occurrence in any changelog; just like features and bug fixes.
This gives non-tech product owners "permission" to remove bloat. Devs stop whining about "the big rewrite". And end-users don't suddenly have to learn yet another tool with "basic" features missing.
I think the best example is google (https://killedbygoogle.com/) and the worst is the amazon shopping website (what a mess!).3 -
I have done something super sacrilegious.
I switched from VIM to VSCode on my Linux box. I got tired of having to constantly configure a tool when I wanted it to GTFO so I could focus on code.
VSCode is the only major tool I couldn't give up from leaving Windows. You get brownie points here Microsoft.
VSCode + VIM plugin + Fira Code + Linux = happiness.2 -
So, I worked away from our software teams and directly with engineers for a few months to examine the capabilities of a new piece of hardware we expected to integrate with. It wasn't necessary that I be shut out from all the other software projects, but my boss decided that I shouldn't go to them. When pressed, he said he didn't want the meeting to be too full.
I studied this hardware thoroughly, and even know the engineers who designed it personally. This is, in every sense of the word, my project.
... So when the product owner asks to meet to discuss another feature around it, my boss decides he should invite the rest of my software team to meet with the engineers. There's some non negligible engineering background behind the tool and associated workflow.
When asked why he invited them, despite me being concerned about lack of focus in the meeting, he said he "didn't want anyone to feel left out".
This is the same man that cost me an entire week of work (and is now costing me my time with the systems experts) because he doesn't want to hurt the feelings of my junior colleagues. He's shown repeatedly that he's just fine excluding me, but heaven forbid my junior colleague feel junior.
I don't think he'll ever realize how much he's playing favorites here. Ugh. -
I used to worked for an IT consultancy in the UK and they would get trainers in to do courses a few times a year. There was this course on UML and people told me how great it was but I was very reluctant. My degree had covered UML and syntax for drawing diagrams to me is the most pointless and boring waste of time ever.
Turned out diagrams were just a tool and the real focus was on design. Anyway the teacher for the course was Kevlin Henny. He really is a fantastic speaker. I learnt so much about object oriented design from the course. These days I keep an eye our for any recordings of his talks.
Here is one of his talks if you are interested:
https://youtube.com/watch/...1 -
The story of a normal release:
- tool gets tested "intensely" by 3 ppl quite a long time - everything works
- a major 2 days reserved as maintenance window for even more testing
- release starts
- first the admin panel of the server suddenly is not accessible anymore
- after some problems the tool is deployed
- suddenly servers are down and not pingable anymore - off on off on (provider has major problems .. good job)
- ppl start testing
- testers report lots and lots of new bugs - seems like the testing wasn't that intense after all...
- people start coming with lots of new requirements (oh we need to import those excels.. excels don't match our internal stuff.. )
- confusion over confusion
- getting pissed of a lot...
- quit caring and focus on another project
- profit
Fuck my life -
I don't care about market cap. Stick your hype-driven business practices up your ass. Infinite growth doesn't exist. I won't read your fucking books and attend your fucking bootcamps and MBAs. You don't have a business model. Selling data is not a business model. Fuck your quick-flip venture capital schemes, and especially fuck your “ethics”.
I will be the first alt-tech CEO. I only care about revenue. The real money, not capitalization bubble vaporware. You don't need a huge fleet of engineers if you're smart about your technology, know how to do architecture, and you're not a feature creep. You don't need venture capital if you don't need a huge fleet of engineers. You don't need to sell data if you don't need venture capital. See? See the pattern here?
My experience allows me to build products on entirely my own. I am fully aware of the limitations of being alone, and they only inspire lean thinking and great architectural decisions. If you know throwing capacity at a problem is not an option, you start thinking differently. And if you don't need to hire anyone, it is very easy to turn a profit and make it sustainable.
If you don't follow the path of tech vaporware, you won't have the problems of tech vaporware, namely distrust of your user base, shitty updates that break everything, and of course “oops, they raised capital, time to leave before things go south”.
A friend of mine went the path I'm talking about, developed a product over the course of four years all alone, reached $10k MRR and sold for $0.8M. But I won't sell. I only care about revenue. If I get to $10k MRR, I will most likely stop doing new features and focus on fixing all the bugs there are and improving performance. This and security patches. Maybe an occasional facelift. That's it. Some products are valued because they don't change, like Sublime Text. The utility tool you can rely on. This is my scheme, this is what I want to do in life. A best-kept secret.
Imagine 100 million users that hate my product but use it because there are no alternatives, 100 people in data enrichment department alone, a billion dollars of evaluation (without being profitable), 10 million twitter followers, and ten VC firms telling me what to do and what data to sell.
Fuck that. I'd rather have one thousand loyal customers and $10k MRR. I'm different, some call it a mental illness, but the bottom line is, my goals are beyond their understanding. They call me crazy. I won't say it was never about the money, of course it was, but inflating your evaluation is not “money”. But the only thing they have is their terrible hustle culture lives and some VC street wisdom, meanwhile I HAVE products, it is on record on my PH. I have POTDs, I have a fucking Golden Kitty nomination on health and fitness for a product I made in one day. Fuck you.7 -
My best tool for avoiding procrastination and getting a lot of focus is having a job with a great work culture in which I get to work on a project that challenges me and makes me learn new stuff. When it's not like that, I tend to lose energy and that sends me straight to devRant and other sources of distraction.
-
First, realize that trying to accurately estimate how much time something is going to take is akin to accurately predicting the future and that people who ask you to do it are stupid. Then realize that sales-oriented deadlines are the source of all that is evil. Then shift away from sales oriented software. Instead focus on selling existing features and new features on the roadmap have no deadlines, they're done when they're done. Then realize almost no workplace will let you truly do that because chasing the sale is all that matters despite the latest buzz word rhetoric. Then estimate enough buffer to give you a reasonable time to complete it without calling your abilities into question. Then finish it faster so you score points with management, but not every time because then they'll begin to expect it. Now you have leveled up in mind games, an unfortunate but necessary tool in the tool belt. Then hate on sales oriented software some more, rinse and repeat.
-
So I figure since I straight up don't care about the Ada community anymore, and my programming focus is languages and language tooling, I'd rant a bit about some stupid things the language did. Necessary disclaimer though, I still really like the language, I just take issue with defense of things that are straight up bad. Just admit at the time it was good, but in hindsight it wasn't. That's okay.
For the many of you unfamiliar, Ada is a high security / mission critical focused language designed in the 80's. So you'd expect it to be pretty damn resilient.
Inheritance is implemented through "tagged records" rather than contained in classes, but dispatching basically works as you'd expect. Only problem is, there's no sealing of these types. So you, always, have to design everything with the assumption that someone can inherit from your type and manipulate it. There's also limited accessibility modifiers and it's not granular, so if you inherit from the type you have access to _everything_ as if they were all protected/friend.
Switch/case statements are only checked that all valid values are handled. Read that carefully. All _valid_ values are handled. You don't need a "default" (what Ada calls "when others" ). Unchecked conversions, view overlays, deserialization, and more can introduce invalid values. The default case is meant to handle this, but Ada just goes "nah you're good bro, you handled everything you said would be passed to me".
Like I alluded to earlier, there's limited accessibility modifiers. It uses sections, which is fine, but not my preference. But it also only has three options and it's bizarre. One is publicly in the specification, just like "public" normally. One is in the "private" part of the specification, but this is actually just "protected/friend". And one is in the implementation, which is the actual" private". Now Ada doesn't use classes, so the accessibility blocks are in the package (namespace). So guess what? Everything in your type has exactly the same visibility! Better hope people don't modify things you wanted to keep hidden.
That brings me to another bad decision. There is no "read-only" protection. Granted this is only a compiler check and can be bypassed, but it still helps prevent a lot of errors. There is const and it works well, better than in most languages I feel. But if you want a field within a record to not be changeable? Yeah too bad.
And if you think properties could fix this? Yeah no. Transparent functions that do validation on superficial fields? Nah.
The community loves to praise the language for being highly resilient and "for serious engineers", but oh my god. These are awful decisions.
Now again there's a lot of reasons why I still like the language, but holy shit does it scare me when I see things like an auto maker switching over to it.
The leading Ada compiler is literally the buggiest compiler I've ever used in my life. The leading Ada IDE is literally the buggiest IDE I've ever used in my life. And they are written in Ada.
Side note: good resilient systems are a byproduct of knowledge, diligence, and discipline, not the tool you used. -
I know this is utopic, but I've been thinking for a while now about starting an open source platform for figuring out the problems of our society and finding real world, applicable, open source solutions for them.
To give you some more details, the platform should have two interfaces:
- one for people involved in researching, compiling issues into smaller, concrete chunks that can be tackled in the real world, discuss and try to find workable solutions for the issues and so on
- one for the general public to search through the database of issues, become aware of the problems and follow progress on the issues that people started working on
Of course, anyone can join the platform, both as an observer (and have the ability to follow issues they find interesting) and/or contributor (and actually work with the community to make the world a better place in any way they can).
Each area of expertise would have some people that will manage the smaller communities that would build around issues, much like people already do in the open source community, managing teams to focus on the important thins for each issue. (I haven't found a solution for big egos getting in the way yet, but it would be nice if the people involved would focus on fixing stuff in stead of debating about tabs vs spaces, if you know what I mean).
The goal of this project would be to bring together as many people from all kind of fields to actually try to fix this broken society.
It would be even better if it attracted people with money and access to resources (one example off the top of my head being people like Elon Musk) that could help implement the solutions proposed by the community without expecting to gain profit off of it (profit is also acceptable if it is made in a considerate, fair and helpful way, but would not be promoted on the platform).
The whole thing would be voluntary work; no salary, no other commitment than the personal pledge that once someone chooses to tackle something, he/she will also see it trough (or at least do his/her best).
The platform would be something like a mix of real time communication, issue tracker, project management tool and publishing platform.
I don't yet have all the details for how it should all fit together, but if there is something that I would like to start, this is definitely it!
PS: I don't think I can ever do something like this by myself, and I don't really have the time to manage a community of developers to start work on it right now. But if you guys think something like this is something worth your time, I will make time and at least start on defining the architecture and try to turn this into a real project.
If enough people are interested, I will drop any other side projects and do my best to get this into the world!
Thank you for reading :)6 -
I had a pretty good year! I've gone from being a totally unknown passionate web dev to a respected full stack dev. This will be a bit lengthy rant...
Best:
- Got my first full time employment dev role at a company after being self-taught for 8+ years at the start of the year. Finally got someone to take the risk of hiring someone who's "untested" and only done small and odd jobs professionally. This kickstarted my career, super grateful for that!
- Started my own programming consulting company.
- Gained enough confidence to apply to other jobs, snatched a few consulting jobs, nailed the interviews even though I never practiced any leet code.
- Currently work as a 99% remote dev (only meet up in person during the initialization of some projects.) I never thought working remotely could actually work this well. I am able to stay productive and actually focus on the work instead of living up to the 9-5 standard. If I want to go for a walk to think I can do that, I can be as social and asocial as I want. I like to sleep in and work during the night with a cup of tea in the dark and it's not an issue! I really like the freedom and I feel like I've never been more productive.
- Ended up with very happy customers and now got a steady amount of jobs rolling in and contracts are being extended.
- I learned a lot, specialized in graph databases, no more db modelling hell. Loving it!
- Got a job where I can use my favorite tools and actually create something from scratch which includes a lot of different fields. I am really happy I can use all my skills and learn new things along the way, like data analysis, databricks, hadoop, data ingesting, centralised auth like promerium and centralised logging.
- I also learned how important softskills are, I've learned to understand my clients needs and how to both communicate both as a developer and an entrepeneur.
Worst:
- First job had a manager which just gave me the specifications solo project and didn't check in or meet me for 8 weeks with vague specifications. Turns out the manager was super biased on how to write code and wanted to micromanage every aspect while still being totally absent. They got mad that I had used AJAX for requests as that was a "waste of time".
- I learned the harsh reality of working as a contractor in the US from a foreign country. Worked on an "indefinite" contract, suddenly got a 2 day notification to sum up my work (not related to my performance) after being there for 7+ months.
- I really don't like the current industry standard when it comes to developing websites (I mostly work in node.js), I like working with static websites (with static website generators like what the Svelte.js driver) and use a REST API for dynamic content. When working on the backend there's a library for everything and I've wasted so many hours this year to fix bugs and create workarounds related to dependencies. You need to dive into a rabbit hole for every tool and do something which may work or break something later. I've had so many issues with CICD and deployment to the cloud. There's a library for everything but there's so many that it's impossible to learn about the edge cases of everything. Doesn't help that everything is abstracted away, which works 90% of the time but I use 15 times the time to debug things when a bug appears. I work against a black box which may or may not have an up to date documentation and it's so complex that it will require you to yell incantations from the F#$K
era and sacrifice a goat for it to work properly.
- Learned that a lot of companies call their complex services "microservices". Ah yes, the microservice with 20 endpoints which all do completely unrelated tasks? -
I usually have some kind of ambient music running in the background like Noisli...Helps me focus better...1
-
A very long rant.. but I'm looking to share some experiences, maybe a different perspective.. huge changes at the company.
So my company is starting our microservices journey (we have a 359 retail websites at this moment)
First question was: What to build first?
The first thing we had to do was to decide what we wanted to build as our first microservice. We went looking for a microservice that can be used read only, consumers could easily implement without overhauling production software and is isolated from other processes.
We’ve ended up with building a catalog service as our first microservice. That catalog service provides consumers of the microservice information of our catalog and its most essential information about items in the catalog.
By starting with building the catalog service the team could focus on building the microservice without any time pressure. The initial functionalities of the catalog service were being created to replace existing functionality which were working fine.
Because we choose such an isolated functionality we were able to introduce the new catalog service into production step by step. Instead of replacing the search functionality of the webshops using a big-bang approach, we choose A/B split testing to measure our changes and gradually increase the load of the microservice.
Next step: Choosing a datastore
The search engine that was in production when we started this project was making user of Solr. Due to the use of Lucene it was performing very well as a search engine, but from engineering perspective it lacked some functionalities. It came short if you wanted to run it in a cluster environment, configuring it was hard and not user friendly and last but not least, development of Solr seemed to be grinded to a halt.
Elasticsearch started entering the scene as a competitor for Solr and brought interesting features. Still using Lucene, which we were happy with, it was build with clustering in mind and being provided out of the box. Managing Elasticsearch was easy since there are REST APIs for configuration and as a fallback there are YAML configurations available.
We decided to use Elasticsearch since it provides us the strengths and capabilities of Lucene with the added joy of easy configuration, clustering and a lively community driving the project.
Even bigger challenge? Which programming language will we use
The team responsible for developing this first microservice consists out of a group web developers. So when looking for a programming language for the microservice, we went searching for a language close to their hearts and expertise. At that time a typical web developer at least had knowledge of PHP and Javascript.
What we’ve noticed during researching various languages is that almost all actions done by the catalog service will boil down to the following paradigm:
- Execute a HTTP call to fetch some JSON
- Transform JSON to a desired output
- Respond with the transformed JSON
Actions that easily can be done in a parallel and asynchronous manner and mainly consists out of transforming JSON from the source to a desired output. The programming language used for the catalog service should hold strong qualifications for those kind of actions.
Another thing to notice is that some functionalities that will be built using the catalog service will result into a high level of concurrent requests. For example the type-ahead functionality will trigger several requests to the catalog service per usage of a user.
To us, PHP and .NET at that time weren’t sufficient enough to us for building the catalog service based on the requirements we’ve set. Eventually we’ve decided to use Node.js which is better suited for the things we are looking for as described earlier. Node.js provides a non-blocking I/O model and being event driven helps us developing a high performance microservice.
The leap to start programming Node.js is relatively small since it basically is Javascript. A language that is familiar for the developers around that time. While Node.js is displaying some new concepts it is relatively easy for a developer to start using it.
The beauty of microservices and the isolation it provides, is that you can choose the best tool for that particular microservice. Not all microservices will be developed using Node.js and Elasticsearch. All kinds of combinations might arise and this is what makes the microservices architecture so flexible.
Even when Node.js or Elasticsearch turns out to be a bad choice for the catalog service it is relatively easy to switch that choice for magic ‘X’ or component ‘Z’. By focussing on creating a solid API the components that are driving that API don’t matter that much. It should do what you ask of it and when it is lacking you just replace it.
Many more headaches to come later this year ;)3 -
This is the first project that I remember. There were probably others before it, but nothing really stands out before this.
My buddy and I got an Independent Study together in high school. Our goal was to write a video game. We harbored no illusions that it was going to be the best game ever or anything, it was supposed to be a project that taught us enough to move on to something else later.
Our chosen tool for this endeavor was Flash 4.0, back before Adobe bought Flash. I don't know why we thought it would be a good idea to do this. I think it was because we could let Flash handle all the graphical stuff and we could focus on the behavioral side.
I don't really remember much about how the project turned out other than we both learned a lot about what not to do.
Luckily, the teacher overseeing our Independent Study felt that the lessons learned were more important than the product, so we got high marks. -
Best thing about having two screens and rectangle is that you can collect all the security pop-ups on the smaller one and just continue working till it's actually convenient to restart everything. (Like after the meeting)
Seriously corporate security measures are completely fucked. Not only did they manage to slow down even Go compiles to a crawl with defender and other crap. Just tried to write 6 words to our PO. Focus got stolen by 4 of the 6 words typed.
One of them demanding to restart Firefox and that one can't be closed or moved out of the way unless you have some fancy window manager tool. This isn't security this is harassment.4 -
I've been studying a bit about business analytics and intelligence to diversify a bit from dev.
After a lot of looking around I've found it's all just glorified jargon which basically enables your decision to have backing of facts and logic. It sounds as if it's a great coverup tool but don't know if it actually helped decision-making.
Why does researching the market/competition need to have a thousand breakdowns/categories/focus areas.
I feel like an interpretation of business analytics is a very simple and intuitive solution but there is just too much random and wasteful metrics attached to it.
I believe it's just my nascent knowledge and experience speaking, but I never felt the same way about software development, financials, etc2 -
Burr puzzles, I love the way they challenge me, they also improve focus and helps with attention to detail. Great tool for ADHD.