As a mediocre, how do you understand complex systems? How do you effectively read internal documents and designs so you can take out information for your particular use case?

I feel like my intelligence is less than average and I either deep dive too much or too shallow. I am slow and coming on to a decision about my use case after reading through is next to impossible for me but my teammates are fine with these.

Break things down into the smallest components you can and learn the smallest first. Usually they build on each other. In the case of them not building on each other, panic.

I usually try to read the documentation and either sketch out what it's saying or if I have access to the program itself go see if I have access to it.

For most people, you can't just scan the documentation once to get the idea, you might end up looking at it 2-3, hell even 10 times to ensure you got all the information you need.

If it's a particular use case scenario, I would recommend making sure you're use case is as detailed as possible, i.e. more detailed than say a standard UML use case might be, and look for items that fit specific details and build out from there.

@TestInProd423 I agree looking at code provides more consolidation. Also, I agree that I have to go through the documentation 2 or 3 times.

I feel short of time doing these activities though, any tips to speed these things up?

@vomitmachine Haha thanks :) Braking down surely helps, but I feel short of time doing all these activities, any tips?

When they assign me to a completely new project, I always start with reading documents withouth deep diving into details. Just to see big picture. Then I start over and try to understand every feature in detail. I am doing this second iteration almost like I'm testing its bussines logic. I try to find bugs in bussiness logic. I never fully understand everything before I complete developing few features. I keep looking at documents as I develop. This works best for me. Sometimes I lost in details too, trying to make things perfect and I don't think thats sign of low intelligence (:

I think I need more info as to what your usecase is.

I don't just read documentations, I start solving the task at hand. Once you know, as an engineer what the problem is and how to attack it then you know what to start looking up in the documentation or code. Chances are, if you are doing something that was already done you can find the solution in the code and just repeat it, if It's something new you first need to know what your idea of a solution is, where you'd start and start looking for keywords in the documentation.

I wouldn't read the whole thing to learn and memorize it, i'd learn the system by using it or maintaining it and looking up answers for the specific questions I have...

@true-dev001 I'd use what @Hazarth said and go off that. If you're breaking something down a specific use case is very helpful. It keeps you on track. Put a break point down and follow the code. Start asking what each class's job is, if there aren't any function summaries or block summaries, add them. It helps you talk yourself through the code.

If you're in corp code usually you'll have patterns and shit, so it helps to know those as well. But if you know how an engineer structured one piece of code and that person wrote other pieces of code, chances are you'll understand a majority of the other as well at a glance.

Login into project and check what kind of fundamental building blocs are those systems are not created in couple months. I worked on some where people worked years to develop it and yes it is big and decision to keep all code in 1 place instead of splitting into microservices was correct. Usually those systems are created by modules so just recognise different modules and where they sit in the code. If helps you can draw on paper. Documentation is not always up to date but this is like everything. Full tests coverage is wishful thinking and not happening because of budget limits and speed required to release features/modules. If someone is paranoid about having big code base to work, think about plane seats. Those are not hanging outside the plane windows on a network cables 🙂

Like if you find a job fixing cars, and you get told Something is wrong with the transmission, you don't go and read the entire assembly manual for the car, you check it out by eye, test it in isolated conditions and then once you roughly see what's happening (or not happening) you start to consult the manuals for those specific parts and issues

That's sorta how I approach learning or working on a new system. Say a complex networking solution. You just dive in and selectively research what you don't understand

@Hazarth I try to do selective researching in the start but as I read, because I need to propose an optimised solution, new terms and things starting coming up. These new things are generally internal to the company so I end up having loads of documentation and less connection between all of them.

@rim01 Reading code really helps a lot. But as the internal packages are alot I have to read through the documentation and find the right one which tells the use of the package.

@Hazarth To make it more specific, I have bunch of services built for Big data. I have to design my system which will be consuming the data from a table and a data structure I don't know about. I am not able to see the data as I don't have permission and I don't know how to access it.
I have to understand the system first and see if it fits in my use case.

@hack Thank you :)

Yeah iterations are important, I think somedays I'm more stressed because researching shows little progress in your scrums and also when your peers ask for a clear explanation when you still don't know many things.

Intelligence is just ability to learn. I make up for it with spending more time and effort than peers and it has made me highly sought for jobs.

Cognitive ability to deal with complex logic - honestly it's unlikely the average Dev works on something complicated. And if it is complicated it's probably a fuck up since good software is as simple as possible (whilst well designed for extension and change).

Don't give up, work twice as hard as peers on your own time, you will be fine and progress quickly.

@true-dev001 it really comes down to the project/component and how big it is. You can only gain the experience by working smaller projects.

Ideally the first pass should be identifying project the purpose, it's scope, architect patterns, etc. Just simple items that should be clear at a high level. I usually have one question to answer at this point. "How do I explain this project to a non-savy tech person in very simple terminology that won't go over their head" and limit my answer to basically 5 sentences maximum. Once I feel my answer can be used as a good explanation to someone not on the project, I usually then start working on the inner details of the project and understand them.

As a non-programming example, think of solving a jigsaw puzzle. Start with the border or frame and then working on details within the puzzle itself (these details could be a bridge or some sort of landmark that takes up a section of the puzzle.

@TestInProd423 Wow! This is something simple and awesome. I surely can use this. Thanks a lot!

@craig939393 also, I am much better with complex logic now than 3 years ago. You can improve intelligence by working out your brain. And this is legit. I won't mis-sell that you will be the smartest person on the room if you just keep working, but you will probably be among the smartest.

In 2016 I was an intern with NO knowledge of web development and NO background in IT apart from what I learned in lectures for 2 years of uni, which is very shallow knowledge. I was shit and useless and felt miserable but managed to not give up. In 2020 I was technical lead of an international software team in Europe, and I got there by promotion just from being the guy with the answers and working super hard.

Anyway don't give up.

First step: stop beating yourself up with the selection of words that you have been using to describe yourself in previous posts: mediocre, dumbass, bad dev, bad person etc.

It is one thing to recognize that you have short comings in terms of your skillset, the other is to completely destroy your morale and self worth. This industry is hard, engineering is hard and in terms of computer science it is a relatively fast changing and young industry.

Considering what you asked, most of us recognize patterns due to experience and repetition and even then we don't memorize everything, think in algorithms and problem solving, not on syntax and tricks, those items will come later, as soon as you develop a pattern of recognition you will know what you need from the documentation. Note that documents will not be your only point of reference.

Recall this meme: even the most senior of us google simple shit all the time.

You're fine girl. just be patient

@true-dev001

I think Id start by identifying the requirements I or the client/employer wants for the system? Does it need to be cheap? Fast? Robust? What's the availability required? How many accesses can I expect? Do I need a database? If yes, what should it be able to handle in terms of writes and reads, if not what is the load the integrated system will have to handle at min/max?

Answering these questions might help you identify where to look in the existing system, so you can integrate it with your solution the best you can.

It seems you don't even need to understand the entire system, maybe you only need a few key fragments, maybe some API docs only. You can deduce a lot about the data if you can at least see what sort of things are sent into the blackbox

Also if its a realy big system, get a whiteboard or paper and draw it out, it helps a lot

But yeah, don't think you're a bad dev just because It's overwhelming, you're in the process of becoming better :)

@Hazarth Thank you for your answer :)

I agree, looking into and answering system related questions is very important. I'm in process of obtaining the information so yes, I feel overwhelmed as I cannot connect these for now.

Flowchart it, and ask for help filling in the gaps in the chart.

@AleCx04 Hey thanks a lot :) You went through my previous posts to reasearch about me, well I feel good that you wanted to be as much as informed you can be before answering.
I have a question here, how can I practice finding these patterns when I have time? Right now, I am grinding through a lot of information so yes I feel overwhelmed but in general do you I can do something to sharpen my system design skills etc.

@true-dev001 It varies greatly depending on the domain in which you are in. For me (full stack web development) the approach varies depending on the project at hand. But in my case, I keep a repository of common tasks, tools, code samples and scenarios. For each one of the items that I have I have documentation links (how a function or class works as per the manual) as well as code samples either devised by me or from posts that other people have around the web. While most solutions can have a plethora of different application scenarios (authentication, payment processing, form processing etc) I settled for the ones that I understood the most as well as the ones that I found easier to complement/change.

From the above you generate said patterns. Self documenting practices are obviously important if not the most important items in here.

Also, if you have a coworker that you feel comfortable with, you can always ask. no shame in that since everyone should want everyone to succeed

Focus first on what can be done.

Then worry about how to actually do it.

the whole OOP abstraction has been designed for this.

Customer object has .AddToCart(int) function?
probably adds the item of that id to the customer's cart.

point is... it's not about trying to understand the whole damn system at once, NOBODY DOES AND NOBODY EVER DID.

it's about segmenting out. "for this specific task, i need to understand the details line-by-line of this area of functionality, and i need to understand what data flows into it and out of it.

then as necessary, you expand what you need to have line-by-line understanding of.

"oh, this piece of data flowing to me is sometimes weird and it causes weird things to my primary objective code, so let's see line-by-line of whatever produces and gives me that piece of data"

you are not supposed, nor expected, to understand the whole damn thing. you are expected to keep doing aforementioned detective work for every task, as it gets easier, because findings from previous cases accumulate and help you solve the next cases.

that's the knowledge asset/resource thing why companies don't like to fire people who have worked with their systems for long enough.

it's the art of knowing what, when, and to what degree you can ignore which stuff (or assume baselessly things about it) until it shows to be the source of the problem upon which moment you need to stop ignoring, and start investigating.

@vomitmachine pretty much summed up what programming is all about. Always take an idea and break it into smaller subsections and break those subsections up until you have a small enough task that you can finish. then move on to the next one. No one can read complex systems and understand it all together. You always break the code/documentation down.