Jeff Carouth

Web and mobile developer. Agile apprentice.

Day Camp 4 Developers Wrap-up

| Comments

I had the privilege of “attending” a virtual conference called Day Camp 4 Developers. All said it was a successful conference with intriguing content and excellent presenters.

I came into the conference not quite knowing what to expect. The selling point for me on attending this conference was that I don’t see “soft skills” talks touted often enough, and I am a firm believer that one can never be good enough at writing, know enough about the community, managing your career goals and path, have a perfect résumé, or even fully understand the role he or she wants to someday lead. Luckily, this virtual conference hit on each of these topics — okay it is not some strange coincidence, I just think the topics selected and presented are perfect and need to be heard by developers of all levels.

The community

Lorna Jane (@lornajane) presents her session entitled Open source your career, which, as expected, delivers engaging content on how a developer can leverage his or her open source contributions to his or her benefit in terms of career.

Whenever people talk about the open source community I usually hear something similar to, “I would love to contribute to the community when I get some free time,” and it usually ends there. It’s considered an extra-curricular activity. I know I’m guilty of saying and thinking that. In her talk, Lorna points out that “open source” isn’t solely applied to products or projects; it applies to blogging, speaking, events, leadership, and teaching.

The main thing I took away from her talk is the statement she closed with: “When the opportunity comes around, say, “I can do that!” And do it!”

I write good — err, well

Elizabeth Naramore (@ElizabethN) follows up Lorna’s excellent session with an in-depth analysis of what skills are necessary and a workflow to help a developer enter the world of technical writing. She opens by explaining that this soft skill should not be discounted because writing technically will help make you a stronger, more well-developed coder. She’s definitely correct.

She made a few great points in her session.

Firstly, when you look at an open source project and compare it to its proprietary counterpart, if the open source project is to have a chance, there is a simple, three-part recipe for success: 1) the code must be awesome and work 99.999% of the time — yes the decimal places are important!; 2) the UI must be “banging” — her word, not mine; and 3) there must be great documentation. Obviously, with a session entitled _Technical Writin_g, she focused on the third ingredient.

She drove home her point about great documentation with an eloquent, “No one will use your stinking project if they can’t figure it out.” She hit the nail on the head. This also ties in directly with another excellent point she makes that you must chose your words wisely, simplify your message, and use clear logic because clear logic leads to clear writing.

Her technical writing workflow is on point. She emphasizes doing your homework, so to speak, and making sure you are able to not only make your case, but to disprove counter points. She also adds what she describes as the most important step in writing — and I vehemently agree here — is to edit your piece, or, in her terms, to de-suckify — that is, to make it not suck.

A perfect résumé

Scott Gordon (@sgordon70) went through a type of dos and don’ts talk about how he, as a recruiter, interacts with and reads a résumé for his clients. He goes over common mistakes, advice about résumé myths, and the best ways to guarantee that you will not get your resume passed along or, even worse, mocked privately in an office or even publicly on a blog.

I, for one, am glad Scott was able to take some time today to present his views on creating the perfect — or, at least, not the most laughable — résumé. Some of what he said is contrary to what is commonly passed along as truth and it did clear up some questions I had about résumé structure and content.

For starters, Scott started talking about how to approach recruiters or HR representatives when trying to land a job. He says that one common mistake he sees is candidates that know they are under-qualified based on listed position requirements, but try to get by with a statement similar to, “I don’t have 8 years of experience, but I am a fast learner and can think on my feet.” The problem with this approach, according to Scott, is that everyone and their mom is a fast learner and his clients do not wish to pay you to learn on the job. He also states that when drafting a résumé or C.V. it is important to be specific. You don’t want to be “near” to what the position requires, you want to be “spot on” or “exact.”

In regards to objective statements — you remember that statement at the top of the page that more resembles marketing speak than anything else — Scott says that they often put him to sleep. He says to ignore what your high school guidance counselor told you because a lot of the time the objective statement is useless. One example he gives has a statement that highlights the candidates strong organizational skills. That’s fine, but, he says, “when would you wish to highlight your mediocre organizational skills?” The answer is never.

He also holds the position that the one-page résumé is not comprehensive enough. He states that oftentimes he ends up assuming a candidate does not possess a skill because it is not listed on the page before him. He says that with a longer, CV-type résumé he is able to discard parts that don’t help him prove your ability to fulfill the requirements of the position.

His final points address honesty. He speaks on several situations that might cause you to pause when filling out your résumé. For example, if you were fired, he says to say you were fired, but to put it eloquently.

Managing your career

Brian H. Prince (@brianhprince) presented a session about meeting your career goals. Everyone has been asked the question, “where do you see yourself in five years?” and Brian takes time to help you answer that question and then to get there.

One key point that can be found throughout the session is that you must be actively engaged in your career. That sounds almost obvious, but, as Brian put it, you must run your career like a business. He used several phrases that illustrate this point. For example, he reminded everyone that as an employee of a company you are an independent contractor to your company, especially with the at-will nature of our jobs. He also used a quote that he attributed to @dmarsh, “You are in charge of your career, your company is in charge of your job.”

He goes on to talk about how it is important to have a goal and to make sure you are working towards it. As an example, he says that you might have a brilliant idea for a startup. However, if you are working as a bomb disposal technician you are not working towards the goal of getting the startup going. This, he says, can impact your performance at your job and will be noticed by your employer.

He says you must take time to be introspective and make sure that your job is both leading you towards your goals and also is the job that you wish to continue. One tool he uses is to sign a contract with himself that he will continue on in his current position for one more year. He says this removes the Monday-morning question about whether he will be going to work or not. He has a contract, so he will.

Finally, he speaks about goals. He says that it is important to set a five- year goal first. Then you can set a three-year goal and smaller one-year goals that support your five-year goal. Once you have your smaller goals, he says to start a checklist of things that will allow you to accomplish your goal.

The role of a software architect

Josh Holmes (@joshholmes) presented a session that helped to define the role of a software architect as well as the various roles that the architect must play in the software development project. The specific roles discussed are explorer, advocate, and designer.

The explorer, Josh says, is the exciting role to play because it usually involves dealing with cutting-edge technology. He says that explorers must find the business problem that needs to be solve and the technologies that will solve it. The explorer is a visionary that looks at technology trends and figures out ways that these technological trends will help the organization within the next two years.

However, he cautions architects that you must explore the pros and cons of the emerging trends. One technique in accomplishing this exploration is to create small-scale, exploratory projects that will test the technology. You must then provide concrete data that proves the pros and cons. Without knowing the cons of the technology, you are not an architect, you are a fanboy, Josh says.

The architect acting as an advocate must speak in support of a particular technology. He must be able to meet and surpass the needs of the stakeholders, the users, and the client by listening, observing, and thinking strategically. As an advocate the architect must understand resources, needs, unique challenges, preferences and business climate and how they impact the project. At the same time, he must be able to listen to customers, partners, users, managers, and developers. The advocate becomes the glue between these two categories.

Finally, the architect as a designer is responsible for evaluating the engineering strength of technology. He must be able to translate user needs into functional structures that meet the unique problems of the user. For example, if the users of the software will be in an area with low bandwidth, the architecture should steer clear of simply throwing everything on the web. It simply won’t work.

The architect must ask and answer several questions. For example, the architect must know what problems to solve and how great the solution must be. As an example, Josh uses the Apollo 13 mission. There were very definite constraints such as limited supplies and time which limit the solution in practical ways.

The virtual conference itself

I am glad I attended this virtual conference. If you missed it, the recordings are going to be available for sale in the next couple months. Each of the talks is worth it.

Having not been lucky enough to attend an in-person conference before, I cannot accurately compare the two. However, I know that I did not miss anything too greatly by attending virtually. With the IRC channel and Twitter running in the background, it was easy to expand on what was being talked about in the presentations in real time without disturbing anyone.

Surprisingly I did not really feel like I was only watching a presentation on a shared screen, I felt like I was in a lecture hall from my college days.

That said, I do think that a face-to-face conference has certain advantages. While we were able to share in the IRC channel together, the conversation was easily polluted by other conversations going on. I do have plans to meet up with some people from the virtual conference at Code Works Austin next weekend. If you are going to be there, feel free to ping me and we can meet up.

The other drawback to this conference was the timing and the breaks. As a first stab at the conference, there were a few surprises that we all had to survive. But survive we did. I would attend the conference online again — okay, maybe not the exact same conference, but you know what I mean.

Cal Evans, the event organizer, posted his thoughts on the conference. Go read them for more in-depth discussion on the virtual conference platform.