DEV Community: Cindy Wu

hello

Cindy Wu — Mon, 22 Jun 2020 03:15:51 +0000

hello world

my friends call me cindy

three months as a develubber

Cindy Wu — Thu, 08 Mar 2018 08:04:50 +0000

We are nearing three months since switching roles. Being a develubber is hard, but not as hard as I originally imagined.

The great thing about being a develubber is that the problem space is often well defined. The not great thing is that there are often an infinite number of ways to solve the problem. What is worse for a new develubber such as myself, is I can write something that works but it is unlikely to be how an experienced person would write it. I have no idea if the thing I cooked tastes good, but it is edible.

I don't know what I don't know

This is still a problem. I don't know when this will stop being a problem. It is impossible to know everything about a single language. If that is impossible, a lot of things are impossible. There just isn't enough time. And, even if you had infinite time learning everything is probably not the best use of someones time.

Learn by doing

I've come to the conclusion that the best way to learn is by doing. So, over the next month I'm going to do more. That means do more coding projects. Do more things that make me uncomfortable and be persistent.

What I keep telling myself is I'm not trying to land Apollo 11 on the moon. I'm trying to move some pixels around and some data through some internet tubes. If I can't do that, there are a lot of other things I won't be able to do.

I feel safe by myself

One of the biggest changes I've seen in myself is I feel safe by myself, most of the time. Because my mind has learned that it is possible for me to accomplish things on my own. If something were true in the past, it is likely to be true again in the future. If there is data showing I successfully fixed a bug in the past by myself, there is reason to believe that I can fix a bug by myself in the future.

Pair more, not less

Jeff and I have started to pair less. I think this is a good sign. It means I can do some useful things on my own. However, I think to keep up the speed in which I learn we need to pair more not less.

I still lack the foundations

I spent all of last night learning about presenters. I kind of understand what presenters are now. I wrote a method in a presenter today, but failed to move the method from the projects presenter over to the updates presenter. I would like to have a stronger foundation in Ruby, Rails, and Javascript. I feel comfortable with CSS, though my CSS is very messy. For the next month, I'm going to commit to understanding the Railsy parts of our app. When I encounter more Rails things I don't understand I'm going to take the time to understand them to the best of my ability.

Do one thing and do it well

When I just code, I make a lot of progress. When I am required to think about other things, I don't code well. If I want to do this thing well, then I should just do this and nothing else. I've made a lot of progress in the last two weeks and that is because I'm not doing anything else. I should forbid myself to think about anything other than code. And then with all my free time, I fill it with creative activities such as cooking, writing, playing music, exercising, and exploring New York City.

Fixing procrastination

Last Sunday, I didn't finish my homework. I tried to think about why. The last ten percent is hard. I love starting projects, but I'm not very good at finishing them. I need to work on my self discipline.

I've also learned if I don't want to program, then the best thing to do is not program. The best thing for me to do is to do something else that requires my full attention for about an hour and then come back to programming. What I should not do is read things on the Internet. One of the best things I can do is read physical books, write, or exercise.

I still struggle with procrastinating on things that appear difficult. I don't have a good remedy for this, but maybe pairing here will help.

Worrying about what to build while worry about how to build it
My dream is that someone can tell me what they want built and why they want it built, so I can worry about how I am going to build it. I would love to be a full time engineer. I do enjoy it a lot. It is probably less that I enjoy being a develubber and more that I enjoy learning.

Making progress

The good thing about being a develubber is that when you make progress it is obvious. You fix a thing. You make a thing that does a thing.

This week was the first time I made a mailer by myself. This week was the first time I submitted a real PR by myself, not just a PR that fixes a bug. This week was the first time I felt like I could really build whatever I wanted if I wanted to.

Being a develubber can be frustrating at times, but I've learned that those moments of frustration are confined to short periods of time that are largely within my own control.

I like this diagram that Jeff showed me during our one on one. He says Mike's house is on the far right. One day, I hope we can all be neighbors with Mike.

four weeks as a develubber

Cindy Wu — Thu, 08 Mar 2018 08:01:53 +0000

Being a develubber is hard. For the past two days, I've been studying the payments code from when a project is finished to paid. This is the first project where I have to sift through existing code in a codebase that is very daunting to me.

The past two days have also been difficult for me because I'm trying to do other things on top of this one task. I've taken 3 meeting with coaches, called a potential intern (I should have said no to this), chose to follow-up with the Shark Lab folks that I met last week over email and Facebook, got sidetracked with the Overdeck foundation giving $1M to DonorsChoose and wrote our own press release, and on top of that it snowed today so I worked from home. I should have gone to the office today.

If I learned anything from these two days is that if I want to be a more effective develubber I should do one thing and do it well. That means do the develubbing and say no to everything else. This is really difficult for me to do.

For the past 4 years my brain has learned that I am most effective when I multitask. Multitasking when develubbing I think slows me down. I don't know if I have a real solution for this other than to be extremely self disciplined.

Let's say that I become extremely self disciplined about saying no and only focusing on develubbing. What is new that is difficult about develubbing?

I am missing the fundamentals

There are certain things about Rails that I am unfamiliar with. This is the first project in a long time where I've had to read a lot of Rails code. I think I should spend a weekend reading a Rails book just to refresh my memory. Again, I think I am missing the fundamentals.

Learn by doing

That said, I think one of the best ways to learn Rails is to learn by doing. This is something that I saw that was very effective at the Shark Lab. Everyone there learns by doing. If you don't know how to draw blood from a shark, don't ready a book. Just try it and learn from someone who knows how. This is where Jeff has been very helpful for me. After I did a first pass at describing what happens between finished and paid, walking through my questions with Jeff was very helpful. Though, I think we would have been more effective if we were sitting next to each other in the same room. Though, maybe something like ScreenHero would solve my problems.

Getting overwhelmed because of obvious inadequacies in design

It is easy for me to get sidetracked and once I get sidetracked I can get overwhelmed. Because I am very critical of every part of the product, I get get sucked into a hole really quickly. For example, my task is to document what happens between finished and paid. I found that when I get to things that are designed poorly (i.e. payout form, collection_started mailer) I tend to want to document those things right away. I cannot stand when the visual portrayal of Experiment is not what I expect it to be. That makes me feel like Experiment is lowering our standard for what we claim to be good design. Because I get sidetracked and start to go down these trails, I miss the main mission which is to document what happens between finished and paid.

Procrastination

I find that I tend to procrastinate working on things that seem to be the hardest to work on or seem to be the parts of the code I am least familiar with. I noticed this happened in the past when I encounter a bug that uses javascript. Because I didn't have experience with javascript, when something like that came up I would just avoid that problem because I knew we had 700+ other bugs that I could fix.

To become a better develubber, I really need to force myself to stick to the hardest problems. It might take me longer to figure out and it may make me more frustrated, but I will learn faster. I think what would help me here is if I had longer periods of uninterrupted time. And, I should be at the office not in my apartment where I can wander to the kitchen to make food and then fall into a food coma and pass out.

With all these things said, I am still very much enjoying being a develubber. I feel like I am learning every day and even though I still feel like every day my key learning is there is so much I don't know I don't know, I really do enjoy that feeling. The more I learn the more things I know I can learn in the future. I know that if I keep learning all the things eventually I will run out of time to learn the rest of the things I want to learn. I guess that is an okay way to die.

one week as a develubber

Cindy Wu — Thu, 08 Mar 2018 07:58:52 +0000

I wrote this on 01-21-17, one week after I started calling myself a develubber aka engineer.

one week as a develubber

Jeff sent me this blog post. I got to read it this morning and it made me feel better about my progress over the last week.

In the past week, I read a react book. I think I understood 50% of it. I tried to apply my learning to fixing some bugs in wizard and failed (but learned). And then, I got to apply what I learned about react to help build our new citations feature.

I got the opportunity to pair with Jeff Tuesday to Friday. I felt like I learned the most during the time spent working with Jeff. I think on the first day I felt that I understood 40% of what we were doing. On Wednesday I felt like I understood 20% of what we were doing. On Thursday because on Wednesday I felt like I was more lost, I was less optimistic. But then on Friday I felt like I understood 90% of what we were doing.

I think one of the biggest things that is holding me back is I don't feel safe with code when Jeff is not around, but that started to change on Friday when we split and we started to work on the same problem in parallel. Yay!

One thing that really helped me was when Jeff showed me how he writes comments outlining breaking down the bigger feature into smaller bite sizes. I believe I fully understand what needs to be executed, I just don't know how to write it in the language of code, in this case javascript.

I think one of the biggest things holding me back is my own self confidence and the fact that I'm not familiar with specific languages. When asked to write an if then statement in javascript, my mind literally pulls a blank. I can explain the concepts of what needs to happen in English, but I cannot translate that English into javascript. I want to work on that. I think if I work on understanding the syntax of specific languages we use, I can get past this problem of self confidence.

My general feeling right now is that I conceptually understand what steps are involved in building the things we try to build, but I lack the foundational knowledge of how all the tools function because of my lack of experience. This is a good thing because I get a good idea concrete steps I can take toward improving my foundational knowledge (e.g. learn javascript syntax, use the CSS resources online to become familiar with common properties used, etc.).

Don't give up. Don't get too discouraged. Keep practicing. Practice makes perfect.

Nevertheless, cindy Coded

Cindy Wu — Thu, 08 Mar 2018 07:06:01 +0000

I started coding when I took a CS course during undergrad, but it took me 10 years before I started calling myself an engineer. I should have started calling myself an engineer from the start.

As part of #shecoded I decided that I would publish my private journal entries from when I first started seriously teaching myself to code.

one week as a develubber
four weeks as a develubber
three months as a develubber

I began/continue to code because...

science needs more coders to build products that make science move faster.

I'm currently hacking on...

experiment.com

I look up to...

people who consistently make time to learn new skills.

My advice for allies to support women and non-binary folks who code is....

ask us what we need to succeed. Be aware that sometimes the best way to help is to get out of the way.

My advice for other women and non-binary folks who code is...

if you're just starting, do not give up. Break down your project into the smallest possible parts and tackle one part at a time. Surround yourself with other coders who are supportive and encouraging. When you want to give up, persist. You will succeed if you do not give up.

If you're an expert make yourself available to noobs. Noobs learn from your successes and your failures. Write openly about your experiences for the younger you.

I'm excited about...

a world where everyone can code. A world where everyone can science.