
Ask HN: Please help me, I'm a bad developer - m3tr0s
I got my degree in computer science about 1.5 years ago. I had and have problems finding and maintaining a job since then. I&#x27;m a frontend developer, and I think I have the necessary knowledge about web in general and practice in JS to be a junior developer at least. However it seems like I have two problems:<p>- I&#x27;m not good at understanding existing codebases. It is not that I can&#x27;t fix a single bug or implement a new feature, it is just I&#x27;m slow. How can I improve this? I&#x27;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&#x27;t want to start another stupid practice project at home while I stress myself out about when will I find a job again.<p>- 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&#x27;m not talking about 1.5 hour long scrum groomings or reviews, sometimes I can&#x27;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?<p>Thank you!
======
hallihax
> \- 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.

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.

~~~
croo
I would strongly emphatise 1) Get enough sleep! For motivation and general
guidance on getting enough sleep please read the book "Why We Sleep: Unlocking
the Power of Sleep and Dreams" by Matthew Walker.

------
cblum
> 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?

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.

~~~
m3tr0s
> 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.

Or if the scrum master noticed it, and started shaming you in front of
everybody to repeat what the other guy just said.

------
Topgamer7
Are you getting enough, good sleep? Have you consulted a doctor about having
ADHD? Sounds like you might have it. Development is a brain intensive task,
getting a full proper night's sleep will make quite a difference. Try to find
if you have sleep apnia, or get 8 hours a night.

~~~
phaus
>Try to find if you have sleep apnia, or get 8 hours a night.

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.

------
CyberFonic
Sounds like a serious problem. From your description there is most likely an
underlying medical reason for your difficulty in maintaining concentration in
meetings, classes and when faced with reading and understanding code.

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.

------
bigato
I started programming in 1989 and I still don't know exactly how to approach
understanding big existing codebases in a productive way. I am pretty well
career wise, though. So, don't worry too much about that point.

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.

------
EnderMB
The advice already given is good, but a few other points I'd like to add:

* 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.

~~~
m3tr0s
> 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.

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.

~~~
EnderMB
Ah, sadly that's fairly standard - hire a cheap junior developer, expect the
world of them, and fire them if they show even the first sign of not being
able to do everything they ask with 100% certainty.

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.

------
deesep
You struggled through the university, but managed to get a degree in computer
science. That's awesome. Now focus on training your focus. Attention is a
complex neurological activity that's more than the sum of its parts. You must
learn to take possession of your mind in a vivid manner of one out of many
possible trains of thought.

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.

~~~
m3tr0s
> You struggled through the university, but managed to get a degree in
> computer science. That's awesome. Now focus on training your focus.

Thank you for the encouragement!

------
arthev
Existing codebases: I'm starting my first job soon and expect this'll be a
challenge for me as well, since it's not covered in curriculi. My plan is to
spend some time during the (short) summer break poking at
[http://aosabook.org/en/index.html](http://aosabook.org/en/index.html) .

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...](https://www.supermemo.com/en/archives1990-2015/articles/sleep)
.

~~~
devinjflick
Hmm I'm interested in the sleep article you posted but the link doesnt seem to
work

~~~
arthev
Yeah, for some odd reason it doesn't load when I click it either. If I refresh
the new tab, it loads though. Weird. Anyway, you should be able to find it
easily by doing a web search for 'supermemo sleep'.

------
tmm84
Understanding existing codebases is something that takes experience, time and
drive (money, rep, etc). There are some codebases that I had trouble with
because they weren't even decent. Tools like grep, looking at previous commits
and an open notes file are good tools.

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.

------
trumbitta2
The second point smells like ADHD or something similar.

You should go see a professional. Some cognitive issues can be rather easy to
treat or at least improve, these days.

------
jraph
For paying attention: have you tried to take notes (even if you throw them
away afterwards, but you might as well keep them)?

It may force you to focus. It may not work at all. It cannot hurt to try?

------
mabynogy
Do you like programming? If you can say yes continue. You probably struggle
with similar problems we all have. It's not particularly your fault.

------
dusted
Sounds like ADHD or something similar, have you checked that out ? Even if you
don't have, some of the coping mechanisms may still work out well for you.

------
ddgflorida
If you decide the developer role isn't for you, there are other roles you may
excel at- QA, Testing, BA, DBA, Data Analyst, Networking, ...

~~~
FishAngular12
Could you briefly describe how someone who’s a Developer with a CS Bachelors
Degree could transition into a Data Analyst role? Would this be a step down,
with less room for growth?

------
laurieg
You say you have trouble finding and maintaining a job. How many jobs have you
had, how long has each one been and how did each one end?

------
Madmallard
Sounds like something for which you need professional assistance. Seek it.

------
samuraiseoul
I had a similar experience when I first started out and I got fired from my
first two development jobs so maybe my experience can help you.

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!

~~~
m3tr0s
Thank you for your answer. I got fired from my two last development jobs too.

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?

~~~
samuraiseoul
I think the second place might have been a bit of bad luck, bit of not reading
between the lines. It sounds like you can code well enough and your co-workers
like you if you got positive feedback except for productivity and meeting
issues which sounds like you're a good developer, but maybe have issues as an
employee.

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?

------
Jugurtha
0\. Understanding a codebase:

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
    
    

2\. Skills

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.

