Skip to main content

Bigger Picture

I've learned a big part of development since I've been a part of this team. We have meetings. Some seem long-winded, some seem unnecessary at times, but I've gotten something from all of them in every case. There's a lot of communication involved in this role. I focused on a lot of technical, but there are many soft skills involved to make it successful. Below is a summary of some of the things I've learned in just a few quick months.




1. Know When You Don't Know

There's nothing wrong with not knowing. There are developers on this team that I've heard everyday say, "I"m not sure how to do that, I need to ask 'so and so'." I feel I'm part of a great team, and maybe this type of honesty isn't the norm. In any case, it's refreshing to see that type of behavior. It's also encouraging to see someone who has been here for many years not afraid to admit when he/she doesn't know something. No one is going to know everything, but it's a great practice to let others know you don't as well. In a way, it instills confidence that you are not going to just do something half-way. Someone who isn't afraid to show weakness is someone who will build on them and make sure the end produce is of great quality.

2. Get Help

This is closely tied to the first item. These same people are not afraid to ask for help. The group I'm in has also become accustomed to easily both give and ask for help. There are five developers, a couple of Product Owners, and a Scrum Master. I've never gone to any of them and gotten a negative response on anything I need help with. From all accounts I've seen, they are like this with each other. They're very quick to give credit where it's due, and they aren't afraid to admit when they needed help, helped someone else, or struggled with something.

3. Experiment

Experimentation is the way of the developer in many cases. Many of the developers are off-site, but I sit with one on occasion here in the same office. I've watched him mess with a section of code and simply go, "okay, let's try this." He'll try it, run it, test it, and note the outcomes. There are times he just simply doesn't know, but before he asks, he'll try a few things. If it works, he often times doesn't mind asking someone else to look over his code to make sure there are no problems. Actually, we have regular "code reviews" on all of the changes, but he'll get an extra set of eyes at time beyond that. He also involves me at times to see what I think might work. It's great exposure.

4. Own Your Mistakes

And when the invariable mistake happens, these developers own it. They investigate the problem, see what happened, why it happened, and when it's pinpointed, it's a very quick, "That was my mistake. How do we fix it?" A great practice I see everywhere, regardless of career choice is not just owning mistakes, but proposing a solution. I had a supervisor tell me once, "If you're just in here to tell me problems with a process or department without a solution, you're just bitching. Don't have time for that. Come to me with the problem and a proposed solution, and then we're working with something." I've never forgotten that lesson. It's a great one to live and work by. It's also a trend I see common in the group I'm in, typically. They own their mistakes by not only admitting to them, but working to find a quick solution. More importantly, they learn from their mistakes. There's nothing wrong with making a mistake. Making the same mistake multiple times, that is a problem.

5. Don't be Afraid to Jump In

This ties in to the second bullet-point above. I've never seen a group of people immediately finish something and be anxious to jump on the next item. There's rarely any "sandbagging" that I've picked up on. If something can be done faster than originally estimated, it gets done faster. It's amazing. If anyone needs help, they call whoever, and it's nearly an immediate response. Again, this may all be a part of my group only, but it's something I think is invaluable. If you're not this type of person, maybe you should be and see if the group you're in begins to catch up. If it doesn't... maybe you're in the wrong group.

Conclusion

Being a developer requires a lot of technical skills. Basically, you can't do the job without it. Simply having the skills to write code, however, is not enough. Working in a team requires a lot more, and in most cases, developers are going to be working in a team. My dream is to become a developer. I'd love to work on things at home writing code and maybe being extremely successful at that. In order to get to that point, however, I need to learn how to write code correctly, learn what's expected of a developer, find out how people work together, and many other things. I won't be able to learn that working on my own. I'm really grateful to be a part of the team I'm on to learn these things early.

Comments

Post a Comment

Popular posts from this blog

Starting the Path

Where did it all begin? To start, I love computers. I always have. The technology in them and around us is intimidating to say the least. There are many things I would do differently and wish could be done differently. So, why not me? I decided to actually try computers more than what I had in the past. I can troubleshoot and setup computers with some basic concepts. I couldn't build one from scratch, but then again, I never tried. I loved computers, but it was my hobby. I was afraid that if I turned my hobby into a career, I would lose my hobby because I wouldn't want to mess with computers outside of work. Eventually, you just have to get past that and try it out. I had been in Customer Service for over a decade. I excelled quickly in that department, but it became very clear after several efforts that I was simply not going to move forward in that department. Though I had advanced most of their technology from the first year I was there, created and wrote several poli
Post a Comment
Read more

Time Management

Codefighting Progress Okay, first, if you're not following my other blogs, it's worth noting that I'm simultaneously studying to become a pilot. I had no idea the time it's going to take to study everything for the flight school. The amount of information covered is insane and demanding. I'm going to keep both up, but not nearly at the pace I had initially hoped. The actual ground school lasts 12 weeks, and then I take a written test. I'll have to get actual flight time in and eventually take the flight test within 2 years to be a full blown pilot. That being said to iterate how much my focus will be divided briefly, but I will come back more focused to this task at hand. I'm in the 2nd week of the 12 week close so only 2 1/2 months left, then my flying time is only on the weekends. I'll figure out how to do that. As far as the what I've been doing lately, well, I haven't progressed further than the 2nd chapter in the book. In my spare
Post a Comment
Read more

Progress on the Pet Project

So, I don't have much, but I do have some. Behold my genius code for my hours calculation:     Private Sub btnCalculate_Click(sender As Object, e As EventArgs) Handles btnCalculate.Click         Dim s1 As Integer         Dim s2 As Integer         Dim s3 As Integer         Dim s4 As Integer         s1 = Val(txtTimeInSunday.Text)         s2 = Val(txtTimeOutLunchSunday.Text)         s3 = Val(txtTimeInLunchSunday.Text)         s4 = Val(txtTimeOutSunday.Text)         lblSundayHoursTotal.Text = s4 - s1 - (s3 - s2)         Dim m1 As Integer         Dim m2 As Integer         Dim m3 As Integer         Dim m4 As Integer         s1 = Val(txtTimeInMonday.Text)         s2 = Val(txtTimeOutLunchMonday.Text)         s3 = Val(txtTimeInLunchMonday.Text)         s4 = Val(txtTimeOutMonday.Text)         lblMondayHoursTotal.Text = m4 - m1 - (m3 - m2)         Dim t1 As Integer         Dim t2 As Integer         Dim t3 As Integer         Dim t4 As Integer         s1 = Val(txtTime
Post a Comment
Read more