Tomorrow will be a live episode of the Podcast at Delphi.org
You can join us live on YouTube with your questions and comments, or catch the replay posted here. Stay tuned tomorrow for details on how to join.
This is our first time with this new format and would love to get your feedback. We’ll also appreciate your patience as we work out the technical details.
U.S. News an World Report just ranked Software Developer as the best job for 2018. They use data from the U.S. Bureau of Labor and Statistics to rank jobs based on pay, job security, mental engagement, stress, room to advance, satisfaction, and work-life balance. Since you are here, you most likely agree with that ranking and are surprised it took so long for someone else to recognize it.
This means we will see a lot of people interesting in software development. Anyone looking for a better job is likely to start at the top of that list and work their way down until they find one they are interested in. Not to mention everyone who sees the headlines about Software Developer replacing Dentist as the #1 Best Job. Whatever the reason, software developers will get a lot more attention.
When I’m talking to people about career advice I think it is more important to choose a career that suits the individual (internal factors) than basing the decision purely on external factors like pay, etc. That being said, I honestly believe Software Development is only going to get more important. Going forward, software development and related jobs (many of which aren’t even invented yet) will consume the many of the other jobs as automation and artificial intelligence take over more aspects of our life. It all depends on which side of the automation revolution you want to be.
When I was really young (like 3rd grade) I knew I wanted to program computers for a living. A family friend told me that I should look for a different job because by the time I entered the career market computers would be programming themselves and there would be no jobs. I remember thinking once that happens there would be no jobs, and someone would need to teach the computers how to program themselves better.
Just recently I was in Tokyo for the 10.2 launch event. I was talking to members of the press, and one of them made a similar assertion “What is the point of releasing better developer tools when soon computers will be programming themselves?” I shared the story from when I was a kid and said that “Yes, AI is automating and consuming other jobs, but the programmer will be the last to go. Once AI’s no longer need humans to make them better there will be no jobs for anyone!”
So what does this mean for you, as a software developer today? Congratulation’s you choose wisely! But be prepared for a lot of people to come to you for career advice. Remember that Delphi offers a great Free Starter edition, and Embarcadero Academy is full of content for people learning to program.
If you aren’t familiar with the Law of the Instrument, otherwise known as Maslow’s hammer/gavel, or the golden hammer it is often expressed as
If your only tool is a hammer, you treat everything as like a nail.
My understanding is that the law of the instrument means you are limited by instruments or tools you know how to use. For example, if you have a screw, some wood, and a hammer, then you might successfully get the screw into the wood, but a screwdriver would be a better alternative.
The law of the instrument also means an obsession with the perfection of the instruments you know. I remember back in the day when I was convinced there was no reason to bother with any other programming languages because Delphi was the best. Now I’ve spent some time using a lot of other programming languages, and so I can confidently say Delphi is the best, while I can see the value and use of other programming languages.
I believe it is worthwhile learning about new technologies, frameworks, languages, or methodologies. Then you can pick the correct one for the job. This doesn’t mean you need to be an expert in all of them, but you should know enough that you are confident in your choice.
The reverse of this is the obsession to chase new and exciting technologies and recreate things every few years. This keeps the developers entertained, but doesn’t really provide business value. Again I believe Delphi does a good job with this as it respects your existing code while moving forward to new platforms, features, and frameworks.
So what is the Curse of the Programmer?
When I’m talking to other programmers I see two behaviors. The first is, every problem they encounter in life (at work and beyond) they respond with “I could write a program to do this,” or some variation. By extension, they also cast a critical eye toward any software system (even those developed by themselves) to see how to do them better. This results in a huge backlog of projects that they create to fix problems, fix a problem better, or just out of curiosity to see if they can.
This is similar to the Law of the Instrument, but I see it more as your learning the flexibility and power of programming results in your seeing many opportunities to apply it. I’ve talked to people in other industries, and I think the general tendency is fairly universal, it is just that programming is (in my opinion) so much more powerful and flexible than many other applied technologies.
The second behavior, which is something to be more cautious about falling into, is the urge to create a “library” or “framework” instead of finishing the program at hand. For example, you are creating a program to solve a problem, and in the process, you create series of libraries just in case you need to solve similar problems.
There is value in having reusable libraries, functions, components, and frameworks. The trick is to not let the creation of them get in the way of shipping. The best way I’ve found to deal with this is to only create the library when you need it. Write your code with the appropriate level of coupling to solve the problem at hand. When you need to reuse a bit of it elsewhere, consider refactoring it into something reusable. Then as you use it in more places you can keep refactoring it and expanding it until you have a full blown framework.
How do you see the Curse of the Programmer in your life? What do you use to prevent every project from spawning a series of reusable frameworks?
The joke goes that, when asked, the software developer responds that their New Year’s Resolution is “7680×4320” or 8K. Joking aside, tradition has it that at the turn of the year we evaluate our lives and look for areas of improvement. Here are a few of my software development related New Year’s #CodingResolutions!
How about you? What are your New Year’s #CodingResolutions?
I had an opportunity to see Uncle Bob speak a few years ago, and it was very memorable. This session will be like no others you’ve seen. He is speaking on “The Clean Coder – An Introduction to Software Professionalism.” His session and the live Q&A will be available only during the live CodeRage session, so be sure to join Uncle Bob for this amazing session!
Early on I learned Turbo Pascal, which was a huge step up from the Basic and Batch File programming I cut my teeth on. When Delphi came along I thought it was brilliant and fell in love immediately. I had no interest in learning other programming languages or tools. Delphi did it all, and that was great. I found myself plenty of work and enough to keep my interest.
I was curious about other programming languages, from an academic point of view. I took a night school class in Assembly. I had a smattering of C & C++. Looked at some Ruby (back before it was hip), Java, JavaScript, etc. Eventually, I found myself spending a few years debugging laser printers, which ran a combination of C/C++/COM all on a Linux platform.
From there I went back to full-time Delphi programming, but the new company I was working for bought into the “there aren’t enough Delphi developers” myth and decided to move to C# & WinForms. We immediately were able to hire some new C# developers, but as we got to know them we found out they had more Delphi experience than C#, but they bought into the “there are no Delphi jobs” myth and rebranded themselves as C# developers. (This is what we call a circular argument or self-fulfilling prophecy.) In the end, the project took 4 times longer than it should have, despite having more developers, and “more modern developer tools.” They really should have stuck with Delphi.
I moved to a new job doing Delphi development full time, and then that company bought into the C# & Silverlight are the future. Since I had C# experience, I started working on the new Silverlight front end. The back end and the desktop app remained in Delphi (with a little C++). We all know what happened with Silverlight (if you even remember it . . .)
From there I ended up really branching out. I did a lot more work with C#, Xamarin, Java, JavaScript, Objective-C, and Oxygene (known as Delphi Prism at the time). There was still some Delphi mixed in too. I taught a few classes and workshops on Android development with Java. I learned to appreciate some of the benefits, strengths, and qualities of each. I found things about all of them I liked (less so about Objective-C).
It was at this point I could see that most developer skills work across languages, tools, and platform. There is value in knowing and using multiple languages. The basic tenants of each language influence the way you do things in other languages, in a positive way, helping you to look at problems in a different way. There are some projects, platforms, and problems that are best suited to certain programming languages and tools. For example, if you are working with the web, you need to know at least some JavaScript, HTML & CSS (the latter two not being programming languages, but I digress), even if you are using some sort of abstraction layer.
Throughout all of this, I still found myself choosing to Delphi for personal projects. Occasionally I’d try personal projects in other tools and languages as a way to get to know them better, but I still found Delphi to be a better solution for most general purpose projects. One of the defining characteristics of Delphi for why I keep coming back to it is that it makes the common tasks really, really easy while keeping the rest simple and possible.
Other tools that focus on productivity, make a small subset of tasks as easy as Delphi does, but also make anything beyond those tasks, or the that “ideal” scenario, hard or impossible. While other general purpose tools don’t do anything to optimize common scenarios, which makes simple tasks more complicated than they need to be.
Now with multi-platform development Delphi is more important than ever. The approach Delphi and FireMonkey provide make it quick and easy to do the most common tasks, while also keeping all the platform APIs and features within reach.
Delphi really invented the 3rd party component market as far as I am concerned. From the beginning, it shipped with all the source code for the VCL and also included a robust OpenTools API and component model making easy for others to extend the IDE, and build reusable components and libraries. All the technology partners are a huge part of why I choose Delphi.
Delphi also has a huge commitment to the code we as developers develop. I attend a lot of general software developer groups, and it is common to hear developers complaining about how they just finished porting their code to support a new version of their tools, only to have it all break again because a new release of their non-Delphi programming language or framework just came out. Often times they just throw it all out and rewrite to support a new version. Sure, Delphi it isn’t perfect, and sometimes there are incompatibilities or breaking changes from version to version, but by comparison, Delphi is so much better at this than any other language or platform out there that I have seen.
I started out choosing Delphi because it was what I knew. Now I choose Delphi because it gets the job done better than the alternatives. The fact it is faster for development is nice, but only part of the equation. I used to have a hat that said “Delphi does it all, especially Windows” and that is truer than ever today.
So why do you Choose Delphi? Share your reasons in the comments or on your blog #WhyIChooseDelphi
In this episode of the Podcast @ Delphi.org we talk with Cary Jensen about his new book Delphi in Depth: FireDAC and the upcoming Delphi Developer Days which Cary puts on with Dr. Bob Swart. Nick Hodges, our co-host, was a previous host of Delphi Developer Days with Cary, and I’ve made a number of appearances there as well. They are highly recommended.
Cary’s new 558 page Delphi in Depth book tackles everyone’s favorite multi-platform database access framework: FireDAC. Cary gives it his unique treatment that only he can deliver. He gives special emphasis to all the configuration options available with FireDAC that can help you gain even more performance.
For this year’s Delphi Developer Days, Cary and Dr. Bob are doing things a little differently. They are doing a special workshop focused on database development. You are encouraged to bring your laptop and follow along while you learn from the masters!
Just in case you missed it, Cary also put on a webinar on FireDAC recently that I recommend you check out.
Creating a bootable USB drive from an ISO is pretty easy on Windows, but you end up going to the terminal on macOS. Not a big deal if you remember all the commands. Since it seems like I’m frequently installing something (Linux, Windows 10, etc.) on a different I thought I would make a quick blog post listing the steps for next time.
hdiutil convert -format UDRW -o targetfile.dmg sourcefile.iso mv targetfile.dmg targetfile.img diskutil list diskutil unmountDisk /dev/disk4 sudo dd if=Desktop/targetfile.img of=/dev/rdisk4 bs=1m diskutil eject /dev/disk4
I usually get an error from macOS when I’m done about not being able to read the USB disk. It is also fairly quick too.
This week I am celebrating my 4 year anniversary at Embarcadero Technologies. Time has flown by and a lot has happened. Mostly a lot of good milestones. One of my favorite things is experimenting with developing on new devices, so I thought I would list some the new platforms and devices I’ve developed for with Delphi since joining Embarcadero.
That is a lot of new devices and platforms in four years. And I know I didn’t get all of them (like the Chromecast, the Kinect, Philips Hue Lights, etc.) Just take a look at our supported IoT Device list. I am looking forward to what the next 4 years holds in store for Delphi, C++Builder and RAD Studio.
What is your favorite new platform for Delphi? Or maybe you are a big fan of the fact we now have the free Starter edition?
I was reading Nick Hodges’ Coding in Delphi again last night (insomnia). In chapter 1 on Exception Handling he opens talking about how not to use exceptions. It got me thinking about some of the atrocious exception usage I’ve seen. I thought I would share a few examples beyond the usual exception sins.
The documentation on the Try / Except pattern says that all the code after the Except block gets ran because the exception is handled. Additionally you can call Raise during the handler to send the exception further up the call stack.
I had just started a new job and was sitting with one of the senior developers to fix some bugs and get to know the codebase. He was creating a local object and so needed to free it. This is the pattern he used:
sl := TStringList.Create; try // using sl except raise; end; sl.Free;
I looked at the code for a minute quizzically, and then asked why he did that. He explained that everything after the except always gets ran, so he can be sure the memory is freed, but still let the exception bubble up to the global exception handler so it is logged. I told him that I was pretty sure calling raise in the except block prevented the code after the block from being ran. He assured me he had been writing code like this for a long time, and it always works.
I thought about it a bit more and then suggested we test the code. So we made a little test application with a message after the except block, and forced it to raise an exception, and sure enough, the message didn’t show. (Always test your theories and patterns with test code!)
There was a look of panic on his face. He’d been using this pattern for years, and it was all over multiple codebases. He claimed that the documentation must be wrong or it changed in a recent update, but I tried to assure him that is was clear and always worked that way, he just misunderstood.
This was using an early version of C# and WinForms.NET in Visual Studio. I took over a project and was having a hard time tracking down some odd behavior. Some code just wasn’t being ran, and there was no error messages. This was a project that was really, really early in the development process, and my first large scale project in C#, and I was getting really frustrated.
I finally discovered that an exception was being raised, but it was never showing up as an error. Even if the debugger was attached there was no exception message. The program just kept on running as if nothing happened, but the operation aborts. I started to question .NET’s ability to handle exceptions.
I dug and dug and finally figured out that the previous developer had setup a global exception handling and logging system that captured all the exceptions and logged them into the eventual support database with a detailed call stack. IIRC WinForms apps close automatically if there is an unhandled exception, so having an exception handler is a good idea, but silently logging them seems questionable. And then since there was an exception logging system in place the developer set the project options to have the debugger ignore all exceptions.
The result is an app running completely silent of exceptions, even while developing, but at least support will have a lot of debug information. I talked to the original developer, and he thought it was a brilliant idea, and said it is the first thing he does in all his projects. He just looks in the support database to see if things are working. His logic being users don’t want to see error messages. Not sure how hiding all the error messages is a good idea, especially hiding them from the developer during development.
I was maintaining some code where a previous developer built this system where custom Exception were used to return a complex type system. He built this impressive hierarchy of exception classes, and then only certain types of exceptions were handled at different levels, where the data was needed. So instead of methods returning a result, or modifying a passed value, they all just raised different exceptions, with the properties set to different values.
There are really two issues here in my opinion. The first is raising and handling exceptions is rather expensive. A better option would have been to just create plain old objects (or even interfaced objects) and return them as results. You can still examine their types and decide when to handle them. You would just need to be aware of managing the object lifecycle (the automatic lifecycle handling was his justification for using exceptions).
The second issue is this was just one subsystem of a larger project. It was only this subsystem that used this bizarre data management system. So when you were fixing a bug here there was a mental tax of wrapping your brain around the different architecture. As soon as you figure it all out, fix the bug, and move on to other code you go back to the normal way of thinking. Again paying the mental tax of forgetting the atrocity you just witnessed.
I really believe that in a large project there should be some consistency in how the pieces are architected unless there is a compelling reason to do things different in one subsystem. That makes it easier for developers to work in different parts of the system.
By the way, Nick has a new book out on Dependency Injection in Delphi. You should pick up a copy.
