!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!

First rant here. Long, but please bear with me:

So after slogging my ass off in various early stage startups for over 4 years and keeping up with the almost non-existent development process, I joined an organisation which has some of the brightest and smartest minds I have had the pleasure to work with.

Mind you, this company is the market leader in it's field and has a 50+ people in it's tech team and the quality of work is pretty impressive.

Now for this week's sprint, I was asked to develop a feature which already exists on the Android app and they want to introduce in the iOS app too. The backend APIs are all in place and all I need to do is build it with virtually no dependency. My PM asks me to start with the UI and ask the backend dev for the API list whenever I need them.This is where the story turns.

For my first API, I go to the backend dev and ask him to share the API documentation and he looks at me as if I have asked him to dance the fucking cha cha. With a straight face he tells me that, 'The organisation doesn't maintain any kind of documentation for it's APIs.' Now this really shocks me. Even in a 5 men tech teams I have worked on, we have always maintained a spec doc for the APIs and this is a company which is known for it's tech practices.

Being the new guy I compose myself and ask if they have anything for me here: Postman collection, a workflowy doc, a goddamn txt file; anything which might help me, and he laughs at my dilusion and says no.

Dejected, I ask for a way to get the APIs and I am told that there are only two ways: either I keep bothering the Android dev for the APIs(No, I don't have the access to the android repo and nor am I gonna get it) which he had worked on 4 months back or I install the prod app on my phone, and use Charles to get every fucking API which is really, really annoying.

I thought writing out this rant would make me feel better, turns out it just made me angrier. Why the fuck can't they document such an important thing!?

I am sure this has happened to all of us in some extent with some variations.

Colleague not writing comments on code.
Ask him something like "How am I suppose understand that piece of garbage you have written when there is no comments or documentation?"
This keeps happening for a long time. Some time after, I write a kernel module using idiomatic C and ASM blocks for optimizations (for some RTOS) and purposely not write neither documentation nor comments.
When he asked for an explanation, I answered to everything he questioned as general as I could for "that trivial piece of code".
After that he always documents his code!
Win! 🏆

I started my internship at the end of the year..
Fuck my ass!!! This code I have to work with is a huge pile of shit.
The code base I need to work with is around 40k LOC. It is a mixture of C++, C, Java, Python, Bash and I think I saw some lonely js files around.

A list of awesome parts:
- Paths are hard coded.
- Redundant code everywhere
- No documentation or inline comments available

Most of the comments in the code are just old code that is not used anymore. But the cherry on the turd is the class that should provide all kind of useful functions in my daily routine. About ninety percent of the functions have the same description or nothing. Sometimes a function name says "readSomethingFromSomewhere" but instead it writes something to a file. It is really confusing and I need to check everything twice instead of rely on what the function name promises.
I have also learned why copy paste isn't that good. The brief descriptions of every method in a files are always the same.

getName() - Description: Fork child process
getIp() - Description: Fork child process
getIpv6() - Description: Fork child process.

Surprise: None of these functions forks a child process. :D

Another awesome feature is the thing that they store up to five different versions of libraries. Everyone with slight modifications but no hint which one you need to use. Sometimes it is the newest, sometimes the oldest which is running in production. Another case of try and error.
Oh and my dev machine is a potato with a power supply and a fan. I started with NetBeans and every time I compiled the code it sounds like the machine wants to lift off and leave for a better place. (At this point I switched to Emacs and everything runs smoothly now)

At first I thought that I'm just not that good at coding and understanding a big project from scratch but some colleagues have the same problem. The whole system is very inflexible and it is all about "std::cout"-debugging to check if your changes do what you want them to do.

Currently I'm just trying to fix this mess to make the life for the next student or employee easier. The first month was just frustrating as hell. I need to ask so many questions and most of the time the answer was "I don't know, haven't touched this code in years". Needless to say that my progress isn't that awesome but at least I get a nice payment for 20 hours of work a week.

Really fed up with my colleague and possibly my job. Am starting to doubt am cut out to be a developer

Am a junior java dev , been working working for this company for about 2 years now. Although they hired me to be a java dev, they pretty much exclusively had me working on JavaScript crap because none of the other more senior devs wanted to do even so much as poke JS with a long stick....

Oh and the salary was crap but i figured since i had barely 3 years of exp i thought i would stick with it for a while

But a few months ago after seeing other opportunities I got fed up and threatened to quit , already started interviewing etc
Got an offer, not exactly what i wanted but better than where i was. Went to quit but they freaked out and started throwing money at me. They matched and exceed the other salary and promised to addressed the issues that made me want to leave. Ie get me to work more on the java side of the project and have me work with someone more senior who could sort of mentor me, i had been working semi solo on the js shit till then...

The problem is that my supposed mentor is selfish prick... he is the sort of guy who comes in real early, basically he goes to early morning prayer then come in at some ungodly hour and fuckoff home around 3pm

He does all his work early morning then spends the rest of the day with his headphones on stealthily watching youtube, amazon, watching cricket, reading about Palestine , how oppressed muslims are or building a website for some mosque.

I asked him to let me sit with him so that I could just learn how this or that part of the sys worked , he agreed then the very next day comes in and does all the work before i get in at 9 , i asked him how he did it and he tells me oh just read the code.

Its not as simple as that, out codebase is an old pile of non standard legacy dog shit. Nothing works as it should, i tried to go through documentation online for the various stuff we use , but invariably get stuck when i try the usual approach because it turns out the original devs had essentially done a lot of custom hacks and cowboy coding to get stuff working, they screwed around with some of the framework jars & edited libraries to get stuff to work, resulting in some really weird OSGI errors.

My point is that i cant really just "read the code" or google ...
I gotta know a bit more what was actually modified and a lot of this knowledge isn't fucking documented, theres a lot of " ohhh that weird bug yeah yeah that happens cuz x did this hack some years ago to fix this issue and we kinda built on it, yeah we weren't supposed to do that but heyyy what u gonna do, just do this or that instead"

I was asked to set up a web service to export something, since thats his area of expertise and he is suppose to be teaching me the ropes, i asked him to explain where i should start and what would the general workflow be, his response is to tell me to just copy the IMPORT service and rename it to export then "just do it um change it or something" very helpful indeed (building enterprise application here nothing complex at all!!)

He sits right next to me so i can see how much works he actually does, i know when he just idly sitting there so thats when i ask him questions, he always has his earphones on so each time i gotta find a way to get his attention with a poke or a wave, he will give a heavy sigh and a weary look as he removes his headphones, listen to my question then give me the shortest answer possible before IMMEDIATELY turning away and putting his headphones on as fast as possible regardless of whether I actually understood or even heard what he said. If i ask another question ( am talking like an immediate follow up question for a clarification or something) he will
Do the whole sigh + tired look routing to make me know yeah you are disturbing me. ( god was so happy the day he accidentally sat on and broke them)

Yesterday i caught a glance at his screen as i was sitting down and i think he and another dev were talking about me
That am slow with my work and take forever to get into gear.

Starting to have doubts about my own ability n wether am really cut out to be a developer. I know i can work hard but its impossible to do so when you have no clue where to start and unable to look it up since all the custom hacks doesn't really allow any frame of reference.
Feels like am being handicapped and mocked, yesterday i just picked up my gear n left the office.

I never talk ill about my colleagues, whenever i have a 121 with my mgr i always all is fine, x n y are really helpful etc
I tried to indirectly tell my other colleague about this guy, he told me that guy had kinda mentally checked out of this job and was just going through on auto pilot and just laughed it off (they have been working together for almost a decade and a buddies) my other colleague is pretty nice but he usually swamped with work so i feel bad to trouble him.

Am really Fed up with it all

School gave me 3 DigitalOcean droplets to try out Kubernetes in the cloud, awesome!

Wrote an Ansible script to not only simply install docker and add users but also add kubernetes, nice!

Oh wait, error?! Well I should've known this wasn't going to be easy... ah well no problem. Let's see... Ansible is cryptic as always, it can't connect to the API server? Is it even running?

Let's ssh to the master, ah nothing is running, great. Let's try out kubeadm init and see what happens, oh gosh, my Docker version has not been validated! No problem, let's just downgrade!

How do I do that? Oh I know, change the version in the role! Wait that version doesn't exit? Let's travel to Docker's website and see what versions exist of docker-ce, oh I see, it needs a subversion, no problem.

Oh that errors too? Wait then what... Oh I need a ~ and a ubuntu and a 0 somewhere, my mistake!

Let's run it again! Fails!

Same ssh process, oh wait...

Oh god no...

Kubernetes requires 2 cores and these things only have 1...

Welp, time to ask the teachers to resize my droplet by a small amount tomorrow, hopefully I'll get a new error!

----------------------------------------------

My adventure so far with Kubernetes. I'm not installing it for any serious/prod reason, just for educational purposes. K8s seems like 'endgame' to me, like one of the 'big guys' that big enterprises use so I'm eager to throw stuff at a droplet and see what happens.

Going further down the rabbit hole tomorrow!

Wish me luck :3

(And yes, I could've figured this all out beforehand with documentation, but this is more fun in my opinion)

I really really hope that no one post this,a friend texted it to me and I wanted to share it because made my day.

Idk where it comes, so feel free if know where this came from to post it:

//FUN PART HERE
# Do not refactor, it is a bad practice. YOLO

# Not understanding why or how something works is always good. YOLO

# Do not ever test your code yourself, just ask. YOLO

# No one is going to read your code, at any point don’t comment. YOLO

# Why do it the easy way when you can reinvent the wheel? Future-proofing is for pussies. YOLO

# Do not read the documentation. YOLO

# Do not waste time with gists. YOLO

# Do not write specs. YOLO also matches to YDD (YOLO DRIVEN DEVELOPMENT)

# Do not use naming conventions. YOLO

# Paying for online tutorials is always better than just searching and reading. YOLO

# You always use production as an environment. YOLO

# Don’t describe what you’re trying to do, just ask random questions on how to do it. YOLO

# Don’t indent. YOLO

# Version control systems are for wussies. YOLO

# Developing on a system similar to the deployment system is for wussies! YOLO

# I don’t always test my code, but when I do, I do it in production. YOLO

# Real men deploy with ftp. YOLO

So YOLO Driven Development isn’t your style? Okay, here are a few more hilarious IT methodologies to get on board with.

*The Pigeon Methodology*
Boss flies in, shits all over everything, then flies away.

*ADD (Asshole Driven Development)*
An old favourite, which outlines any team where the biggest jerk makes all the big decisions. Wisdom, process and logic are not the factory default.

*NDAD (No Developers Allowed in Decisions)*
Methodology Developers of all kinds are strictly forbidden when it comes to decisions regarding entire projects, from back end design to deadlines, because middle and top management know exactly what they want, how it should be done, and how long it will take.

*FDD (Fear Driven Development)*
The analysis paralysis that can slow an entire project down, with developments afraid to make mistakes, break the build, or cause bugs. The source of a developer’s anxiety could be attributed to a failure in sharing information, or by implicating that team members are replaceable.

*CYAE (Cover Your Ass Engineering)*
As Scott Berkun so eloquently put it, the driving force behind most individual efforts is making sure that when the shit hits the fan, you are not to blame.

Revision to the Peter/Dilbert Principle, the ProjektAquarius principle: a company will systematically shift the least competent employee on to the assignments the competent employees can't be bothered to do until they become an integral part of the team and drag you down with them. (E.g. eventually they completely fuck up your delivery process, although it's probably still cheaper and quicker than having them do anything else.)

ProjektAquarius principle: A Case Study

We have an engineer who is getting paid quite a bit more than me. Over time his responsibilities have gradually been reduced to documentation and running our almost entirely automated build. Well today the build failed. He pulls me over to tell me, and says he's confused because there is a file there he has never seen before in there and a file he always has seen that isn't there (basically a file got renamed. It was not non-obvious). Answer: change the file name.

Then he comes over and tells us that it's failing again because the script is not finding a file. So a coworker of mine and I go over. He explains the whole build process to us when we ask if there is any point in the script that would help us identify where the script is looking for the file and failing (there wasn't but that's besides the point).

Turns out, he had decided to put the assembly list in order. Normally no problem, but the list is in source destination pairs. So the fucking file was being put in a different directory than the one the script was looking for it in and failing. And that's the story about how my company just paid 3 engineers a quarter of a man hour each for something that would have been resolved in 30 seconds via file search/copying and pasting a file path. Related note: our process for building an install is now about 4 hours long with no change on process besides the BCAK.

How to handle a company in which I work as a junior android dev for the past 7 weeks where there is zero mentoring?

I have 2.5 year experience in android dev and then I had a 1.5 year gap. I was looking for a company where I can get back on track, fill my knowledge gaps and get back in shape. So I accepted lower starting salary because of this gap that I had. Me and manager agreed that I will get a 'buddy' assigned and will get some mentoring but nope..

70% of my scrum team with teamlead are overseas in USA and I have just 2 senior colleagues from my scrumteam that visit office only once a week. Ofcourse there are other scrum teams visiting office daily but I personally dread even going to office.
Nobody is waiting for me in there. What's the point if when I need to ask something I have to always call someone? I can do it from home, no need to go to the office.

My manager dropped the ball and basically disappeared after first 2 days of helping me setting up, we had just two biweekly half-assed 1on1’s where he basically rants about some stuff but doesn’t track my progress at all. I bet he doesn’t even know what I’m working on. Everything he seems to be concerned about is that I come to work into office atleast 3 days a week and then I can work remaining 2 days from home.

I feel like they are treating me as a mid level dev where I have to figure out everything by myself and actual feedback is given only in code reviews. I have no idea what is the expectation of me and wether Im doing good or well. Only my team business analyst praised me once saying that I had a strong onboarding start and I am moving baldly forward… What onboarding? It was just me and documentation and calling everybody asking questions…

My teammates didn't even bother accepting me into a team or giving me a basic code overview, we interact mainly in fucking code review comments or when I awkwardly call them when I already wasted days on something and feel like I'm missing some knowledge and I am to the point where I don't cere if they are awkward, I just ask what I need to know.

Seriously when my probation is done (after 6 weeks) I'm thinking of asking for a 43% raise because I am even sacrificing weekends to catch up with this fucked up broken phone communication style where I have to figure out everything by myself. I will have MR's to prove that I was able to contribute from week 1 so my ass is covered.

I even heard that a fresh uni graduate with 0 android experience was hired just for 15% les salary then me. I compared our output, I am doing much better so I definetly feel that Im worthy of a raise. Also I am getting a hang of codebase and expected codestyle, so either these fuckers will pay for it or I will go somewhere else to work for even less salary as long as I get some decent mentoring and have a decent team with decent culture. A place where I could close my laptop and go home instead of wasting time catching up and always feel behind. I want to see people around me who have some emotional intelligene, not some robots who care only about their own work and never interact.

You work in a team, for a team to move forward successfully the team should work in sync. A team always has a goal and a plan to get to it. There are times when the team needs to take a different direction therefore the set path should always be available for change because our environments dictate it.

We all have different styles of working and different opinions on how things should work. Sometimes one is wrong and the other is right, and sometimes both are wrong, or actually sometimes both are right. However, at the end of it all, the next step is a decision for the team, not an individual, and moving forward means doing it together. #KickAssTeam

The end result can not come in at the beginning but only at the end of an implementation and sometimes if you’re lucky, during implementation you can smell the shit before it hits the fan. So as humans, we will make mistakes at times by using the wrong decisions and when this happens, a strong team will pull things in the right direction quickly and together. #KickAssTeam

Having a team of different opinions does not mean not being able to work together. It actually means a strong team! #kickAssTeam However the challenging part means it can be a challenge. This calls for having processes in place that will allow the team members to be heard and for new knowledge to take lead. This space requires discipline in listening and interrogating opinions without attachment to ideas and always knowing that YOUR opinion is a suggestion, not a solution. Until it is taken on by the team. #KickAssTeam We all love our own thinking. However, learning to re-learn or change opinions when faced with new information should become as easy to take in and use.

Now, I am no expert at this however through my years of development I find this strategy to work in a team of developers. It’s a few questions you ask yourself before every commit, When faced with working in a new team and possibly as a suggestion when trying to align other team members with the team.

The point of this article, the questions to self!

Am I following the formatting standard set?

Is what I have written in line with official documentation?

Is what I am committing a technical conversion of the business requirement?

Have I duplicated functionality the framework already offers?

I have introduced a methodology, library, heavily reusable component to the system, have you had a discussion with the team before implementing?

Are your methods and functions truly responsible for 1 thing?

Will someone you will never get to talk to or your future self have documentation of your work?
Either via point number 2, domain-specific, or business requirements documentation.

Are you future thinking too much in your solution?

Will future proof have a great chance of complicating the current use case?

Remember, you can never write perfect code that cures every future problem, but what you can do perfectly is serve the current business problem you are facing and after doing that for decades, you would have had a perfect line of development success.