In this episode, we discuss working with those from other technical disciplines, and also touch upon the software skills that engineers should possess.
Our guest for this episode is Paul Davis, a software engineer who currently writes jet engine control code.
Although there is some dispute about the quotation’s origin, EdsgerDijkstra is frequently credited with proclaiming that “Computer science is not about machines, in the same way that astronomy is not about telescopes. There is an essential unity of mathematics and computer science.”
Computer science relies on a number of developments found in discrete mathematics.
Paul’s first job after college involved getting Windows 3.1 users connected to the internet via a program called Winsock.
His next job found him managing a VAX cluster that ran on the VMS operating system.
To gain software development experience, Paul earned a masters degree in Software Engineering from Embry–Riddle Aeronautical University in Daytona Beach, Florida.
Paul found the study of formal methods, using Z notation, to be both useful and intellectually challenging.
In an old blog post, Jeff reasoned that software engineers are really “engineers.”
Since code can be easily changed, tweaking software is often the lowest cost “fix,” but can cause unimagined and unintended consequences.
Paul has encountered a number of engineers that use an interface package, such as Simulink, to isolate them from having to generate low level code.
Engineers can benefit from learning more about software development, according to Paul, since so much of modern engineering involves programming.
Writing code is the best way to learn about coding issues. Paul suggests Python, since it is a widely supported language with a lot of goodtutorials.
Does anyone actually read these show notes? Perhaps I could simply string together random words like baseball, snowshoe and bubble gum.
Jeff struggles to describe a linear variable differential transformer (LVDT), even though he taught a Mechatronics course this past spring. He promises to do better in the future!
Paul suggests that software developers specialize in a particular domain, and that physical engineers strengthen their awareness of software concerns.
Software is an important component in the toolkit of nearly every engineer. Chris and Jeff talk with Greg Wilson about how engineers and scientists can improve their programming skills.
Intended to encourage good programming practices, Pascal gained wider acceptance as the basis for Borlands’s Turbo Pascal.
Programming in the 1970’s was not carried out at a terminal, but required punching data cards on a keypunch machine, then feeding the cards into a card reader. Yes, that huge stack of spinning “magnetic disks” at the 1:14 mark is an early hard drive.
Our guest for this episode is Greg Wilson, who is the founder and director of Software Carpentry, an outreach and training program that helps scientists and engineers be more effective by teaching them “best-practices” for software programming.
Greg’s work with Software Carpentry is currently funded by the Sloan Foundation in the United States, and he is an employee of the Mozilla Foundation.
Software Carpentry seeks to reach the majority of researchers, scientists, and engineers who build “small” data projects, rather than the relatively few that work on “huge” data sets using supercomputers.
A typical Software Carpentry workshop consists of a two-day course, with blocks of instruction addressing the Unix shell, Python, version control, unit testing and SQL. The two-day workshop is often followed up with about six weeks of online instruction.
Greg says that if participants come away with nothing else, they should learn the value of version control, so that the provenance of scientific data can be tracked and analyzed.
The Software Carpentry team has found screencasts to be “a lousy way to teach,” as personal interaction is an important component of learning.
Greg has found engineers to have a bit more “hands-on” experience than scientists, and to be more MATLAB-oriented, but perceives relatively little difference in their understanding of software issues.
Considerable empirical research has been conducted about programming effectiveness, but little of this information is shared with students in college courses.
One of the most critical indicators of how well individuals can work together in a corporate programming project is not their geographical separation, or language differences, but how far apart they are in the company’s organization chart.
Pair programming is an effective method for reducing software errors, but it has an important caveat: it only keeps working if you keep shuffling the coding partners.
The single most effective way to find bugs is code review. Don’t compile the code, or run it, but have someone else read through the code. You’ll find 60-90% of the bugs in the first reading. Review Board is an open-source web-based tool designed to help in such efforts. A commercial product for this purpose is available from Smart Bear Software.
Mark Guzdial has been using “worked examples” to teach programming at Georgia Tech, and has found it to deliver more learning in less time.
A flipped classroom has students watch instructional videos for homework, and then spend class time working problems.
In a 2009 blog post, Greg talked about “real” engineers becoming more like software engineers, rather than the other way around.
Greg believes that higher quality software is possible, if the right incentives are offered to programming organizations.
Even if we can’t review code line-by-line, we can at least verify the methodology and processes used to create it.
This week we talk to Ian Dees, software engineer at Tektronix focused on mid level software and ways to improve the longevity of electronics that use software over time.
Ian focuses mainly on C and C++ but also moves into higher level languages and other aspects of product design while working on oscilloscopes.
What makes things sustainable 10 years down the road?
Architectural changes (that’s “refactoring”, not “rewriting”) can really help short term changes.
Planning schedules can end up affecting longevity. However, making software (or hardware) too extensible can create paralysis analysis.
Software designers often have to deal with the evolution of languages as well, vs having similar concepts in electrical engineering and mechanical engineering over the years.
Reliability and longevity are the same thing over time.
Chris likes working on redesigns in order to learn about what not to do and how to design for the long term.
Jeff felt drawn towards different bits of software that would “solve problems” when in fact they’ll only solve one aspect and then create new ones.
Ian now works with a marketing person who doesn’t just wave off the difficulty of a task; there is trust between engineering and marketing to help get a better grasp on schedule estimation.
What would happen if engineers-in-training were subjected to a pile of code with no tests?
Jeff learned hands on with drilling and tapping threads into old mills and learning the warts in a realistic product.
Expected lifetime can also affect the longevity of a product. Should there be a planned obsolescence or maintenance schedule?
In this episode, we discuss working with those from other technical disciplines, and also touch upon the software skills that engineers should possess.
