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

New Pet Project

Okay, I've got my next great idea for my pet project. It's a little more complicated, but not terribly. My biggest complaint I had when I transferred from the Detailing Department to the Customer Service department was the loss of my trusty HP48G calculator. This thing was awesome! You calculated feet and inch calculations with formulas. The format was feet.inches and sixteenths. For instance, 14.0608 = 14'-6 1/2". The formulas removed parts of the inputted number and converted them from a foot to a number to add and subtract, and then reconverted the number to a foot answer to display. I and a colleague created several excel sheets that essentially did the same thing, but it just wasn't convenient and didn't flow very well. So, I'm going to create a program that looks close to this calculator. In addition to the addition, subtraction, multiplication, and division of feet-inch numbers, there were formulas that calculated roof slopes, weights, and...
Post a Comment
Read more

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

Pet Project Progress

Well, I've started my pet project, and I've got a GUI laid out. It's a little slow going, but it should work well in the end, I think. I'm sure there's going to be lots of feedback and many different ways I could do things. Right now, however, I'm limited to what I am learning in the text. As promised, here's the screenshot of my first program. Help? I'm trying not to ask too many people how to write any of the code yet for a couple of reasons. First, I haven't learned any code yet, and I likely won't understand a word of what's being told to me. Second, I'm afraid that what I'll be told I'll understand at that moment, but since I didn't have to work  for it, it won't get burned into my memory like the knowledge I have to seek out. Those long hours searching usually scar you to the point you never want to forget those lessons again. Function Since I don't have too much to show, I'll just explain what th...
Post a Comment
Read more