- I'm not good at understanding existing codebases. It is not that I can't fix a single bug or implement a new feature, it is just I'm slow. How can I improve this? I'm looking for something like a job simulation at home, like list of tasks to do in an existing codebase, with explanation or even guidance. I don't want to start another stupid practice project at home while I stress myself out about when will I find a job again.
- I have problems at paying attention in meetings. I struggled through the whole university too. I understood and learned almost everything at home for 5 years. Sometimes I even got asleep during important classes. I'm not talking about 1.5 hour long scrum groomings or reviews, sometimes I can't even pay attention during a 15 minute long standup in the morning. At my lost job they found it as a serious problem. Where to start?
Thank you!
The best way to improve this is just practice, plain and simple. Check out an open source project you like, and add a feature. You don't even need to create a PR for it - just do things you think might be good / useful - but add them to existing projects. It takes time to figure out how to separate signal from noise with other people's code - you just have to put the hours in.
> I have problems at paying attention in meetings. I struggled through the whole university too. I understood and learned almost everything at home for 5 years. Sometimes I even got asleep during important classes. I'm not talking about 1.5 hour long scrum groomings or reviews, sometimes I can't even pay attention during a 15 minute long standup in the morning. At my lost job they found it as a serious problem. Where to start?
If you can rule out a disorder like ADHD, then some of the best things you can do to improve concentration and attention span:
1) Get enough sleep (you mentioned falling asleep sometimes - a good sign that you're not getting enough generally)
2) Eat well, and regularly.
3) Stay hydrated
4) Take regular breaks (go for a walk, get some fresh air)
No solution is 100% effective - but they're things that have helped me.
IMO that is only a problem if you can’t pay attention in meetings where the points being discussed are very relevant to what you’re expected to contribute.
Most meetings are a total waste of time. The more people in them, the more meaningless they are. It’s natural not to stay engaged. If you think other people are, a lot of people are really good at giving that impression. This usually manifests in the form of completely irrelevant but tangentially related questions being asked.
If it’s any consolation, I think I’m a good (or at least decent) developer given my career progression, rewards, etc. so far, and I space out in 99% of the meetings I attend and that’s rarely an issue (and when it is, it’s a matter of someone telling me one little thing I missed in 1h of blabbering). I’m very open about my opinion on meetings and it’s never been a problem either.
Or if the scrum master noticed it, and started shaming you in front of everybody to repeat what the other guy just said.
Both of these are great suggestions. Up until I was about 26, I occasionally would get in trouble for falling asleep at work. At one job, I had to start around 0700 and it got to the point where I was frequently falling asleep. My boss talked to me about it (one of the kindest managers I've ever had) and she suggested I get checked out. I had previously just thought I was undisciplined but it turns out I had sleep apnea and I was only getting about 6 hours of sleep a day on top of that. I thought you could get used to it but it really isn't enough for most people.
Problem paying attention: It sounds like you might not be getting enough sleep. Best source of knowledge on sleep that I know is https://www.supermemo.com/en/archives1990-2015/articles/slee... .
What exactly happens? Does your mind wander? or do you feel tired? Do you drive? if so how is your concentration on longer trips? How is it that you are better able to learn at home? What is the difference?
As @Topgamer7 suggests you might be suffering from sleep apnoea. Another possibility is early onset of diabetes. Anyway, you really should see a GP who will most probably refer you to specialists.
I also hate meetings from the bottom of my heart. Maybe that's why you find it hard to pay attention?
Like with the big codebases point, I have a taste for small and simple, so when I start plunging in a big codebase, I have too much moments when I get nervous by how stuff was badly done and that emotional state does not help me focus on the task.
* I also have a degree in Computer Science, but with 18 months of professional development experience I'd still consider you a junior-level developer. In terms of skill level, you're absolutely fine, so don't worry too much about whether you should be better at certain things than others.
* I wouldn't expect a junior developer to fully understand an existing code base without significant time workng on it. I'd also say that the only remedy for being good at this is to spend time working on large projects. CS degree or not, this is a new skill for you, so don't feel stupid for struggling with this. The only way you'll improve is to get a system set up locally, and to debug your way through the system until you understand what individual parts are doing. Some systems make more sense than others.
* I'd agree with the other users on going to see a GP, but I'd also add that you're not the first developer to have their mind wander in a meeting, and you certainly won't be the last. It sounds obvious, but have you considered writing notes during these meetings? I'm sure your PM's and lead developers would be grateful for the notes, and if it helps you to retain knowledge in those meetings then it's a win-win.
They fired me after 2.5 months working on the project, that's why I started to "worry" about my skills. They hired me as the only junior developer and as I think about it more and more, I'm starting to be sure not me wasn't enough, but a junior developer wasn't enough there in general.
It may not seem like it, but it's a good thing to experience a shitty company, because you'll learn as much from how to not do things as you will from the "right" way.
A lot of people have touched on the focusing part. To be honest, I think that you sound like an absolutely normal developer, and all you need is an opportunity to grow at a good company. Out of interest, have you considered working at an agency? In my experience, they're a nice place to start out, because you get to work on numerous small to medium sied code bases over the space of a year, and the breadth of work allows you to build your experience while keeping time pressure on.
Get enough sleep, exercise, read as much as you can on ADHD/ADD, listen to your body, and talk to a specialist. Focus on one thing - improving your focus and attention over time. Who you are and what you do is mostly the sum of what you focus on. Rapt attention is important to achieving your career goals. Take some time out to work on it. Finally, do try to be gentle on yourself.
Thank you for the encouragement!
Meetings are hard if you aren't engaged as part of the meeting. Maybe it is ADHD and you can get counseling/advice on how to handle meetings. I think this is something where a little counseling from a real professional is going to benefit you the most.
You should go see a professional. Some cognitive issues can be rather easy to treat or at least improve, these days.
It may force you to focus. It may not work at all. It cannot hurt to try?
Getting good at grocking through existing codebases is an experience thing I feel. You need to understand the frameworks and libraries used, as well as understand the underlying business use cases. You can look through open source projects or build small example projects with the libraries in question to help you with understanding their code bases.
Understanding a code base is like understanding most other things. If you don't have an understanding of most of the background things, then you don't even know where you're struggling. It's like jumping into a book about quantum mechanics when you don't even know Algebra. You need to learn about the backend they use, the frontend stuff they use, and the business cases. I know that's a re-iteration of what I said above but sometimes having something explained from two ways helps.
As for the meetings and such, I think it is partially the above as well. I know when I first started out, not understanding the business, and the goals of the business, as well as what is in the code base already, nor what can be done in the code base, made the meetings hard. You don't know what they are talking about, why they are talking about it, and can't contribute due to lack of understanding. This makes it boring, like attending a lecture so high above your understanding that it's almost pointless to be there.
If this sounds like a likely scenario, then you just have to study and study and study. Also be honest with your co-workers and manager. Most of the time in my experience if you can identify the problem, figure out a path to fix it, and explain to your manager, they will be on board. Especially if you show that you are working to fix it. Always be introspective about the problems, and never be afraid to look dumb by asking questions. Also maybe confide in another coworker first about your problem if that feels more comfortable than your manager.
Lastly, I know that I had lots of these problems when I had an alcohol problem and drank WAY too much everyday. It made me sleepy in meetings, hard to think about problems, hard to understand new things, and just lots of other things. If you find yourself drinking a lot, perhaps consider doing a month of no drinking to see how that affects things. (I know you didn't mention drinking anywhere but I thought I'd say something just in case)
If you have questions or things just reply! Also maybe look at dev.to as well as they are a more junior community with a softer touch than here and may have lots of advice from people closer to your level or different perspectives that will help!
Good luck!
I didn't like the first place, I haven't got too much help to even onboard, not talking about learning the codebase or the framework. (One thing I will never ever do again is trying to learn a completely different framework at a new job...)
At the second place however I felt I was pretty good. They mentioned areas to improve (productivity, meetings), but most of the feedbacks were good. Then they fired me. They "expected more improvement".
What is the mistake I shouldn't make again? Am I a bad developer, having problems or just unlucky?
Are you currently employed and if so is your current place complaining, and if so is it the same things? I know after having been fired I get a bit of anxiety just thinking about those kinds of things even if I am doing well.
As others said on the falling asleep thing, do ask a doctor about it, you may have an attention disorder or sleep disorder.
Also do you participate in the meetings? If not, why? I found if its a meeting I don't need to be in, or can't participate in then its harder to focus and stay awake.
I also find that I am not good at 'using' my ears. I had trouble learning by listening when I was in class, and also by listening in meetings, I need to read something to have a chance at following along often. If you have a similar thing, ask if they can provide some notes or info about the meeting so you can prepare better. That may help.
I find on productivity, making sub-tasks for the day helps a lot. Something like: * send email about x * ask Y about Z * look into A for project B * do ticket D * fix issues from PR for ticket Q * do PRs for persan M and N
and then I just do those as well as I can each day and break them down into smaller tasks if need be. I don't care if I don't finish them really unless it happens a lot, and I add new things as they come up. I also normally make that list in Slack to myself so I can access it wherever I need to. This will give you a good baseline of where you are in terms of daily productivity. Also be sure that if you're doing a whole bunch of non-dev tasks, and they are measuring you on dev tasks, to talk to your manager about it. That's not fair or they be unaware of all the non-dev tasks.
But it sounds like the commonalities that happened in both jobs were not producing enough, and also sleeping or not being attentive in meetings. Work out why those are and fix those.
Does any of that help?
0.0. Get to know the codebase:
0.0.0. Code distribution:
You can get an overall "idea" of the code distribution, or where the meat is, by using `cloc . --by-file`. This shows you a listing of files and their respective number of lines of code and comments. You instantly get an idea of the "big" files of the project you probably should get to know.
You also see the ratio comment/code and can start documenting and writing tests as you go. It will help you understand the project, and will be useful for everyone and in refactoring.
0.0.1. Structure:
0.0.1.0: Visualization
Drawing helps me. Conceptual blocks of the project. It can start as block names and boxes "Codec", "Streaming", "Persistence", "Dispatcher", etc.
Drawing on paper, whiteboard, etc. You can also use something like "Gliffy" to diagram for yourself and with someone when communicating. You can both change and make sure you're talking about the same thing.
And do it going down the abstraction scale. Higher abstractions to lower abstractions.
I also found a quick automatically generated "UML" diagram helps. I don't write them necessarily, but I use a tool that tells me about the structure of a project.
pyreverse for Python, scaladiagrams for Scala, are just a few examples that generate an image you can save and glance over after the `cloc` stuff.
0.0.1.1: Grep
I use `git grep` on the classes found in the biggest files I found with `cloc`. I can see how they "disseminate" through the project and how they get around and are used
0.0.1.2: Tests
I look at unit tests (if any) to get a sense on what the different parts do and how they're used. You learn a lot about "intent" from the tests if you're lucky to have them. I add tests as I get acquainted with the project.
If there's a CI config file, I'll check it out and it tells me how to deploy the project. It's often more accurate than the readme or else the builds would fail.
0.0.2: Musing
I maintain a separate "musing" file, sometimes called "refactoring" where I'll put a comment with the path to a file and the part it's about (say a function, or a class), and rewrite it. It is separate in the beginning as I don't know if the refactoring is relevant or if there's any Chesterton's Fence and I don't want to pollute the repo. It is my way of grappling with the code. Several rewrites. Often when I'm in a quiet place and my juices are flowing.
0.1. Taking notes for project:
One of my habits from the beginning was taking notes. I can now pull my notebooks at my current job and see the chronology (dated by month) and ordered. I can walk through the different difficulties, conceptualizations, drawings and schematics, sequence diagrams, re-architectures, refactorings, etc.
As you embark on your journey in a project, your fresh eyes are valuable. You're seeing a lot of what has become "normal" for other developers. Note everything. The idiosyncratic build or deployment. Out of date documentation. Everything.
You can create well written issues that follow a template with expected and actual behaviors, screenshots, logs, stack traces, possible fixes, likely culprits, etc.. If your repo does not have a template for issue, propose one.
Write issues in a way to make them easier to fix for everyone. Your group can use your notes to rework an API or the user experience. You're also working to streamline future contributions for newcomers.
0.2. Knowledge Base
As your understanding of the project increases and you touch more and more parts, you can maintain a sort of knowledge base. It is highly likely that this knowledge base will serve as the project documentation if it has none.
1. Attention
1.1 Taking meeting notes:
Many meetings. Few actions. Everybody ends up talking about the same things and issues drag on forever. You can take notes and review them later. Write them up and send them to everyone. Check out minutes of meetings.
You can write the gist of what's said, and the action that must be taken, by whom, and when.
Taking these notes will help mitigate your distraction during the meeting as you can review them at your rythm.
# Minutes of Meeting
--------------------
## Date: 2019-03-25
## Place: BIGCorp HQ. City, State.
## Participants:
### BIGCorp:
- John Doe (jd)
- MeMyself I (mmi)
### OtherCorp:
- Dilbert (db@othercorp.com)
- Dogbert (dg@othercorp.com)
## Topics:
- Scheduled information sending
- Information flow
- Architecture for Project X
## Details:
OtherCorp has raised some issues for the timeline of Project X...
Blah blah blah.
## Actions:
### BIGCorp:
- [ ] @bc: Send project X estimates by 2019-03-28
- [x] @bc: Send invoice and cheque for offices remodeling
- [ ] @mmi: Add different schemes for user authentication
- [ ] @mmi: Finalize migrations so we take into account user's timezone
### OtherCorp:
- [ ] @oc: Expose API end points for user's identity verification
- [ ] @oc: Cache the results of the most common queries
Understand the business value for the customer (what value is your code bringing to the customer, what are they trying to achieve).
Daily improvements. Reading good books and implementing what they contain. Writing the best code you can write. Reading the best code you can find. Consistent, continuous, relentless, improvement.
If you can be better than you were when the day started, and do that daily, good things may happen.
Constantly transfer the quality gains to the projects you're involved in (better documentation techniques, better patterns, less complexity, etc.)
Help others write better code by setting the example. Mentor newcomers to the project. Help write tools for everyone to use.