Ask HN: Please help me, I'm a bad developer

24 点作者 m3tr0s大约 6 年前

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

18 条评论

hallihax大约 6 年前

> - 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 hydrated4) Take regular breaks (go for a walk, get some fresh air)No solution is 100% effective - but they're things that have helped me.

评论 #19917131 未加载

cblum大约 6 年前

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

评论 #19901247 未加载

Topgamer7大约 6 年前

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.

评论 #19926227 未加载

arthev大约 6 年前

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 <a href="http://aosabook.org/en/index.html" rel="nofollow">http://aosabook.org/en/index.html</a> .Problem paying attention: It sounds like you might not be getting enough sleep. Best source of knowledge on sleep that I know is <a href="https://www.supermemo.com/en/archives1990-2015/articles/sleep" rel="nofollow">https://www.supermemo.com/en/archives1990-2015/articles/slee...</a> .

评论 #19901176 未加载

CyberFonic大约 6 年前

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大约 6 年前

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大约 6 年前

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.

评论 #19901356 未加载

deesep大约 6 年前

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.

评论 #19901437 未加载

tmm84大约 6 年前

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大约 6 年前

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大约 6 年前

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?

dusted大约 6 年前

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.

mabynogy大约 6 年前

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.

ddgflorida大约 6 年前

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

评论 #19900103 未加载

laurieg大约 6 年前

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大约 6 年前

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

samuraiseoul大约 6 年前

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!

评论 #19901617 未加载

Jugurtha将近 6 年前

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: VisualizationDrawing 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: GrepI 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 used0.0.1.2: TestsI 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: MusingI 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 BaseAs 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. Attention1.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.<pre><code> # 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 </code></pre> 2. SkillsUnderstand 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.