Extra Credits: So You Want To Be a Developer (Part 2)

This week, we finish discussing the skills it takes to be a great developer (with lots of help from the folks at Stack Exchange).

Show Notes:

Special thanks to Stack Exchange!

Audio Version:
Download

Recent Comments:

  • Some background: I work as a software developer in the the industry (not the game industry though), developing high performance and real time systems.


    Quote:
    Understanding how the code works at a low level is the only way to get high performing code

    I think that's way too strong. In my experience 90-99% of the time, you'll get bigger gains adjusting or replacing algorithms and other high level changes. But that 1-10% does exist, so the advice is still good, if a little overstated.

    Generally I would agree that picking the right data structures and algorithms will often lead to the most significant performance gains. However, it's not always as simple as just tweaking or replacing an algorithm; in modern environments, things like cache misses, false sharing, and other seemingly insidious issues can significantly hamper performance, despite picking efficient algorithms and data structures.

    Combating these issues requires a lower level understanding of how the hardware functions and operates and the the representation of the code in memory (e.g., cache line sizes, variable alignments in memory, locking and sharing across different processors and cores, etc...). I'm guessing that they may be referring to issues like these as well as more general issues such as I/O bound operations, access to/from external data sources, resource limitations, etc...

  • Great episode! This episode applied to ALL software engineering, not just video games. I like the emphasis on communication. If you can't communicate, then you are severely limiting your career. Communication is one of the essential skills I look for when interviewing. If you can't communicate clearly and concisely, then that's a deal breaker.

  • Ah yes communication. I became lead programmer on a local robotics team. We had a programmer 2 years ago who missed every meeting, when we asked him if the code was done he said yes and got defensive. We got to competition and found out that his code was full of memory leaks and basically pissed off the watch dog (the program that makes sure the robot hasn't gone on a rampage or gotten stuck in a feed loop)

    Now i'm not saying that I'm great at communication, i often have the software/hardware argument with the lead electronics coordinator. Or having a builder tell me the robot needs to go fas... I'm ranting,but yes good communication is KEY. Anyone can learn to program or code, it takes skill to be able to co-operate with what your team needs.

    Also on the math point: I personally recommend that anyone who's going to be a developer learn up to basic trig. If for a game studio or anything applied to real world (aerospace, robotics, systems) a little physics wouldn't hurt. :)

  • Ah yes communication. I became lead programmer on a local robotics team. We had a programmer 2 years ago who missed every meeting, when we asked him if the code was done he said yes and got defensive. We got to competition and found out that his code was full of memory leaks and basically pissed off the watch dog (the program that makes sure the robot hasn't gone on a rampage or gotten stuck in a feed loop)

    Now i'm not saying that I'm great at communication, i often have the software/hardware argument with the lead electronics coordinator. Or having a builder tell me the robot needs to go fas... I'm ranting,but yes good communication is KEY. Anyone can learn to program or code, it takes skill to be able to co-operate with what your team needs.


    Actually, you bring up an interesting point I didn't think too much about. Just what do we mean by, "communication?" I mean, we can't just throw the term around and expect every developer -- an infamously socially-stunted profession -- to understand it instinctively. I think a definition is in order.

    First, a dictionary definition to get a good start. Here's Dictionary.com's definition:
    Communication (noun)
    1. the act or process of communicating; fact of being communicated.
    2. the imparting or interchange of thoughts, opinions, or information by speech, writing, or signs.
    3. something imparted, interchanged, or transmitted.
    4. a document or message imparting news, views, information, etc.
    5. passage, or an opportunity or means of passage, between places.

    In software development, when we say, "communication," we mean several things:
    1. your willingness to share information.
    2. your willingness to listen and accept other people's information.
    3. how well you can word your information for another, possibly-not-tech-savvy person to understand it.

    I personally value the willingness to share and listen more than being good at your wording. Most people will improve on their wording when they're conscious about it, and practice on it constantly. The willingness to share and listen, however, has to come from your own will. You shouldn't be protective about what you do, where your progress is at, and how you plan to solve future problems (unless, of course, the job requires you to be so). You shouldn't put down other people's ideas, either. Accept them with open arms, even if they seem stupid. Without that will, you'll end up in the same scenario as runningkrypt0 explained above. Nothing in any teamwork-based environment is more frustrating than one member refusing to share their work or information, whether due to personality, lack of time, or insane shyness. And trust me, even with 500 employees, it can take just one stubborn person to bring a whole project down in a very, very short time.

    Feedback is important! Share your work and knowledge often, listen intently, and ask a lot of question!

  • I'm a retired software developer (I now program for myself rather than someone else). Developer parts I & II are absolutely on-the-money - that is exactly what professional software development is all about. I think there still might have been a little too much emphasis on math skills. Some of the confusion is because the same brain skills are useful for both math and programming, but 40 years of programming for me, have only required high school trigonometry and algebra.

    Programming is logic, not math. It mostly involves begin able to get from point A to point B by breaking the job down into smaller and smaller steps until you have all the pieces ready to string together. The team leaders can break down larger problems into smaller problems and can coordinate them between multiple develoipers.

    The points about working well with non-programming members of the project are critical as well. The reason the suits pay us so well to have fun programming is that our code will get sold to customers for lots of money. The best code is that which can be written once and sold many times. That is where the real money is -- so write every line of code with re-use in mind.

    It is fun for "real" programmers to mock the marketing department, but if they don't bring in the cash, we don't eat, and I would much rather face the blue-screen-of-death than try to make a sale.

    There are still untold billions of dollars to be made programming and I envy the young people just getting started.

    Have fun - Howard

Join The Discussion: