Second Integrate Detroit cohort to showcase midterm project next week

The second Integrate Detroit cohort, from left to right: Joya Puryear, Kim Sanders, Stephanie Vaughn, Clark Vaughan, DeShayla Cisero and instructor Samah Majadla.

There are a lot of people in Detroit with a natural aptitude for computer programming, and if you look for them, you might find them.

Integral Detroit is one company looking for such people, and they have found about a dozen so far. Its spinoff program, the similarly named Integrate Detroit, graduated its first cohort back in late August.

A second cohort will be graduating in a few weeks. Next week, though, they will present their midterm project. Scroll down to the end for date, time, location and how to RSVP.

The program focuses on teaching students test-driven development and pair programming in Java, important skills employers are looking for, but which are not too easy to learn from a book or an online course.

The second cohort started in September, and next week, before Thanksgiving, they will showcase their work on their midterm project, a to do list app. After Thanksgiving, they will come up with an idea for their final project and work on that until graduation.

I had the privilege to be in the first cohort, and our midterm project was an earlier version of the to do list app. The project was set up by instructor Samah Majadla with help from her Integral colleague Nate Dubetz.

We presented our progress on the app at a presentation back in early August. That presentation was in some ways similar to what the second cohort’s presentation next week will be like.

Unfortunately, it looks like I won’t be at the second cohort’s presentation. I’m slated to give a talk about Scala at the nearby Detroit Labs the very same day at roughly the same time. At least I hope to help them rehearse.

I’ve met the second cohort as a group a couple of times. They are a good group of people with a lot of untapped potential. In a neat reversal of the first cohort demographics, they are women, all but one.

Test-driven development is a principal focus of the Integrate Detroit course. I think the second cohort will talk a little bit about what test-driven development and pair programming are like.

Their talk will be more geared towards the general public than my talk, with very few assumptions about the attendees’ knowledge of computer programming.

The first time I heard about test-driven development, it sounded kind of backwards to me. But after going through the class and adopting it for my own projects, I have come to see that often it is the best way to go about a project.

That’s because most of the time, you have a pretty good idea of what you want a program to do, but not a very clear idea of how the program will do it. So it’s much easier to come up with the tests at the beginning of the project.

Here I’m going to give a quick example of test-driven development which I hope anyone who completed high school math can follow along with.

Suppose that you want to write a program that lists prime numbers between 1 and some user-specified threshold, like 250 or 65538. Plenty of people have already written programs that do that.

Maybe you yourself have written such a program. If that’s the case, for the sake of this example, please pretend that you haven’t.

I personally prefer to write stubs first, before anything else. For a more elaborate project that relies heavily on existing programs, stubs really help clarify certain details.

At this stage of the test-driven development process, the stub should give a clearly incorrect result.

The first test should be simple. Like, say, we ask it to list the primes between 1 and 10.

If we have a unit testing framework like JUnit properly set up in IntelliJ, we should see a green play button next to testListPrimes(). Click that button to run the test. The test should fail, because our current version of listPrimes() will give an array that doesn’t contain any primes at all.

The smart-aleck thing to do at this point would be to amend listPrimes() thus:

The next step now would be to write a slightly more elaborate test. You get the idea. I go more in depth on test-driven development in another Medium article.

It’s definitely possible to learn test-driven development from a book. To learn pair programming from a book, that would be a bit more difficult. You really have to pair with another human being.

For this reason, the instructor would prefer each cohort to have an even number of students, to assure that each student can be paired with another student, but realistically that might not always be the case.

And sure, students in Integrate Detroit will work on research and homework assignments alone. But the class projects must be worked on in pairs or in larger groups.

In my opinion, pair programming is difficult only if you or your pair have never done it before. You two might be working on a poorly defined problem, but then that’s what makes pair programming difficult, and then it would also be difficult if you were working on it on your own.

Test-driven development makes pair programming easier. You might disagree with your pair about what the best way to do something is. But if you can write a test, you can run a test and probably see that you were both wrong.

Integrate Detroit is serious about placing graduates in jobs. My first cohort classmate Vaughn Walker is already working at Menlo in Ann Arbor. There will probably be more news like that before the year’s out.

Integral is doing this out of a genuine desire to place Detroiters in software developer jobs. It’s not about getting big cardboard checks from foundations. But if foundations are serious about this cause, they should talk to Integral.

The only obstacle for a foundation, if they choose to see it as such, is that Integral is a for-profit operation, though there has been talk of breaking Integrate off into a non-profit. I don’t know how long that process would take.

I do know that the third cohort is slated to start in Detroit early next year. The location is pretty much set, but there may be some flexibility in scheduling (the second cohort meet weeknights and during the day on Saturdays, just like the first cohort, but the third cohort might have a different schedule).

So if you’re a programming student looking to fill gaps in your knowledge, a hiring manager looking for local talent, a foundation board member looking for worthy causes, or just a curious member of the general public, you should come to the second cohort’s midterm project presentation.

You might see some of the first cohort students, but you probably won’t see me because I’ll probably be at Detroit Labs giving a talk on functional programming in Scala.

For my talk I’ll expect attendees to be familiar with object-oriented concepts like inheritance, polymorphism, encapsulation, etc. The Integrate Detroit presentation is more for the general public. You can RSVP to my talk on a Meetup page.

The Integrate Detroit presentation is slated to take place at the Merchants Row location of WeWork, 1449 Woodward, in downtown Detroit on November 20 at 6:30 p.m. RSVP on the Meetup page.

The entrance for the Merchants Row WeWork is not on Woodward Avenue, it’s on Clifford, if I recall correctly. It’s roughly a block away from Detroit Labs.

is a composer and photographer from Detroit, Michigan. He has been working on a Java program to display certain mathematical diagrams.