More advice for University Students (newbie coders)

Posted on by
2

 

Another older but great article focussing on advice for young developers:

http://blog.codinghorror.com/learning-on-the-battlefield/

Here’s the key advice for students about to embark on a career in Software Engineering:

  • If you’re a student, seek out internships like your life depends on it. Some of the best programmers I’ve ever met have been college interns. Intern somewhere that you can absorb and learn as much as possible. You won’t make much money, but the experience will be priceless.  
  • Participate in local user groups. User groups are an unbeatable resource for people just starting out in their careers; they’re an excellent source of advice and mentorship.
  • Contribute to an open-source project. There are thousands, so pick whatever strikes your fancy. But pick one and really dig in, become an active contributor. Absolutely nothing is more practical than working collaboratively with software developers all over the globe, from all walks of life.
  • Publish articles. The cleverest code in the world won’t help you if you can’t clearly communicate how that code works, or what it’s for. Try your hand at writing.CodeProject is an excellent sandbox to practice in. Publish an article and the large, active CodeProject community will let you know how you’re doing with ratings and comments.  
  • Start a blog. Pick a writing schedule and stick with it; I recommend once a week at minimum. Select a general theme for your blog and write on topics related (at least tangentially) to that theme. And don’t be an echo chamber.

Source: blog.codinghorror.com (2007)

Advice for self taught programmers

Posted on by
Reply

This is a nice article focussing on self taught programmers.

http://blog.pluralsight.com/self-taught-developer-job-tips?utm_source=marketo&utm_medium=email&utm_campaign=Newsletter_15_1202

What I really like the most is the focus on Craft a Portfolio – really like the advice the authors focusses on – this is not just useful for self taught programmers but all programmers should consider this.

A guide for university students…

Posted on by
Reply

I have the pleasure of working with some university students during a summer vacation program. It’s a great experience and their enthusiasm and drive is seriously impressive. For any current university students here is a great article by an absolute legend of the .net community:

http://ayende.com/blog/172609/what-i-wish-they-would-teach-in-universities

Here is a nice little quote:

“I’m talking about actually using a source control system to manage code, to review past work, to see the flow of changes, etc.

What about knowing how to debug? I’m talking about a bit more than F5 and F10. I’m talking about practical things like being able to debug a big system and understand how to work the debugger to give you what you want. Knowing how to look at the stack trace, or understand the difference between an exception that is thrown (and handled) and an unhandled exception.

What about actually solving real world problems? Like a project that has a double assembly reference because of a bad merge, and you need to be able to track it down and fix it.

What about actually reading code? Given a non trivial amount of code, figuring out what is going on and making changes there.”

Ayende Rahien, 2015.

Now if you are a student studying software engineering don’t be disheartened. It’s just that you’ve started a journey and one of the things most seasoned developers will say is “there are no shortcuts”

Design Document Part 10 (What makes a good design)

Posted on by
Reply

I came across a great article recently by Scott Hackett:  http://blog.slickedit.com/2007/05/how-to-write-an-effective-design-document/. It’s a thorough look at the reasons to write Design Documents (dd) and though it’s a few years old now, it covers one of the really important aspects of writing dd’s – What’s a good design?  Here’s a great excerpt:

“A design will typically be considered good if it fulfills the requirements in a meaningful way. If any aspect of the design cannot be justified, then it is probably worth reevaluating. Many programmers try to incorporate design patterns into their work, and they often add unnecessary complexity. You should be able to list at least one compelling reason, related to the requirements, for why a design decision was made. That reason must then be documented. If you can’t come up with a clear reason for a design decision, then it is probably not adding value.”

(Scott Hackett:2007)

This is really important and it’s usually why I start most dd’s with some sort of problem definition (ie. What are we trying to solve? or even what are we trying to build?). If you can at least point your design to that – you are at least focussing your design/solution firmly on fixing a problem. That’s a good start.

“You should be able to list at least one compelling reason, related to the requirements, for why a design decision was made.”

(Scott Hackett:2007)

I also really like the the breakdown that Scott uses for his dd’s. It is a nice clear separation of areas that can be covered in a dd:

Section 1 – State the purpose of your project/sub-system

Section 2 – Define the high level entities in your design: High level entities are objects, or groups of objects, that constitute major constructs of your design. Good examples of entities are a data access layer, a controller object, a set of business objects, etc… 

Section 3 – For each entity, define the low level design: This section is where your objects and object relationships are defined… 

Section 4 – Benefits, assumptions, risks/issues: …”

This breakdown is excellent – it’s not exactly how I split up the dd but it’s logical and it covers a wide range of issues that come up when designing something in Software Engineering.

The last section is really important. It’s a section that you as the developer will not always know at the start. You might actually think “Hey that’s a project managers job”.  I’ll cover that in the next article.

 

 

 

Design Document Part 9 (Design Docs and SCRUM)

Posted on by
3

I get asked a lot about how does a design document (dd) fit into SCRUM. There is generally a deal of concern that the dd slows the development process and even concerns that it’s a fall back to waterfall development.

So, just to remind, the dd can be really small. It can be as small as a number of dot points (or a few sentences) in an email or a photo of a whiteboard used in a design/planning session- particularly for small pieces of work.

A dd works well within SCRUM as a the output of a spike. Reminder about spikes:

“A spike in a sprint can be used in a number of ways:[1]

  • As a way to familiarize the team with new hardware or software
  • To analyze a problem thoroughly and assist in properly dividing work among separate team members.
  • Spikes tests can also be used to mitigate future risk, and may uncover additional issues that have escaped notice.”

A distinction can be made between technical spikes and functional spikes. The technical spike is used more often for evaluating the impact new technology has on the current implementation.

Source:https://en.wikipedia.org/wiki/Spike_(software_development)

What’s really important about that statement is: “The technical spike is used more often for evaluating the impact new technology has on the current implementation”. This is one of the primary reasons we use a dd. It’s to protect the existing implementation and by seeking feedback from experience developers, tech leads and architects the developer is reaching out and using the experience and knowledge of the development team who generally know the most about the current implementation. They are are in a great position to advise on technical direction to avoid  negative impacts on the current implementation.

The dd does not always have to be produced via SPIKE, but certainly in the case where the SCRUM team is considering a new feature with new patterns/libraries/hardware etc.. then it may well be worthwhile investigating a Spike. I like the dd as an outcome of the spike because it is actually meaningful output and can be accompanied by a prototype. I also like the idea of adding acceptance criteria – that’s really for the tech lead/senior developers/architects to accept as part of their review.