The Blog of Maxim Porges

Posts Tagged ‘Coding’

  • How To Become A Software Engineer/Programmer

    Bruce Eckel just posted a blog post about how to get in to a career in computing. He starts by posing the question “should I learn C++ or Java?” and throughout the post indicates how thoroughly irrelevant that question is to a successful computing career.

    It’s a great article overall, but based upon my experience, I think this statement Bruce makes in his post rings truest.

    “When the Internet was first booming, all you had to do was spend some time learning HTML and you could get a job and earn some pretty good money. When things turned down, however, it rapidly becomes clear that there is a hierarchy of desirable skills, and the HTML programmers (like the laborers and sheet rockers) go first, while the highly-skilled code smiths and carpenters are retained.

    What I’m trying to say here is that you don’t want to go into this business unless you are ready to commit to lifelong learning. Sometimes it seems like programming is a well-paying, reliable job — but the only way you can make sure of this is if you are always making yourself more valuable.”

    He also lists the output of a seminar where participants highlighted qualities in ideal job candidates for software developers.

    “There is no right answer … and always a better way. Show and discuss your code, without emotional attachment. You are not your code.”

    I’ve worked with a lot of different programmers in my career, and I’ve found that the best ones had these two qualities Bruce describes in common: a commitment to lifelong learning and emotional separation from their code.

    The guys I worked with who had not committed themselves to lifelong learning typically fell in to the category of people who learned a language because programming jobs in that language were hot at the time they got in. If these are your motivations for becoming a programmer, I have very simple advice for you: choose another career.

    People who learn one hot language just to get a job mostly find themselves ten or more years later as one-trick ponies on outdated software platforms. Since they have no real interest in learning anything else, there’s a huge degree of insecurity associated with learning anything new, which has a direct impact on how they react to ideas to improve their trade. This is easy to spot; instead of welcoming alternative approaches for their merits and engaging in debate, these guys are the ones who will dig their heels in against change and do everything they can to maintain the status quo, regardless of whether or not the solutions are meeting the needs of the end users/software requirements. This is a one-way ticket to a dead-end career.

    I like to consider myself in the other camp, which is programmers who embrace the lifelong learning process. However, I also try to be realistic about my ability to stay in this camp for the long term; there are trade-offs to both career choices.

    To be clear, I love writing software more than anything else about my work, but I also enjoy the occasional breaks from the “grind” when my management responsibilities take center stage. In short, writing high-quality software requires a ton of focus and discipline, and unless you take constant pleasure in this you will find yourself hating your job. When you hear about engineers getting burned out, it’s usually due to being forced to stay in a focused state for an extended period of time. Both (a) the need to constantly change your methods and approaches, and (b) to learn entirely new languages to produce the best solutions and leave your old skills behind require a huge commitment both personally and professionally. Case in point, after ten years in the field, I’ll be learning Groovy from one of the guys on my team next week since we determined that the Grails platform will be the best thing to support our web service endpoints.

    While I don’t know when (if ever) I will get burned out, I could definitely see myself leaving coding behind one day in the future. I’d still be involved with software, but I would replace coding with more managerial responsibilities, perhaps focusing more on software team management or product management needs. If that day ever comes, I think I’ll always be a tinkerer; after all, if you love programming, that love stays with you forever. I learned last week that my periodontist used to be a UNIX programmer before he got burned out, and he still messes around with coding on the weekends.

    I had a chance to get out of coding earlier in my career, when I took on a senior management position. It’s a lot easier to manage software than to produce it as your personal output, and in a different company I probably would have stayed with the management role. However, the company I worked for was not a technology company, and this meant that I spent more time managing the concerns of the business than the development of their software. Since my passion is ultimately for software, I just didn’t care about my career continuing in that direction. I’ve since made the switch to work in the tech sector, and can now honestly say that if I was given the choice between a career developing software in the non-tech sector and switching careers, I would switch careers. So, even if I end up in a primarily managerial role in the future, it will be for a tech company.

    In closing, my advice for budding software engineers is this.

    1) Know that you love software before you commit to it. You’ll know when you take your first pseudocode class: a clear division forms between the people who get it and the people who don’t. If you’re in the “don’t” section, choose another career.

    2) If you don’t like teaching yourself new things, the skills you learn today will be irrelevant in less than a decade. Accept the commitment to learn throughout your career as a coder, or accept your eventual fate as a has-been.

    3) College degrees matter less than hands-on knowledge and time spent at the keyboard. I outpaced my entire class in college because I bought my own programming books that deviated from the coursework, and as a result I learned things they were not teaching in school.

    4) College degrees still matter. There was a lot of stuff I missed in my two-year AS degree at a community college that I ended up learning either through experience, or by rubbing shoulders with colleagues with four-year CS degrees. If you can’t make it through four years of school, make sure you pick up a book on programming algorithms and learn the classics before you hit the workforce.

    5) Early on, decide if you want to focus on application development or software engineering. Application development deals with making user interfaces, interfacing different systems together, solving business process problems, and exposing applications to the outside world (i.e. web services and other remoting techniques). Software engineering deals with creation of utilities and processes that support information processing, tends to be more math intensive, requires a lower-level understanding of the trade, and rarely deals with the systems that expose the software to an end user. There are core differences in these two disciplines and 100 shades in between, so figure out what you like.

    6) Once you know what you want to do, seek a job that puts you in an apprenticeship role with an actual person as your mentor. Companies that support co-op programs and allow you to learn from a mentor while contributing to a team produce the best engineers. If you find that you are plugged in to a position like a cog in a big machine, and have “ivory tower” designers/architects handing out instructions without teaching you the “why”, find another job.

    7) If you decide to program software for a company whose core business is not technology, know that in most of these companies the quality of the software is not important, and your role in the organization is considered expendable. In these companies, IT is usually the first department to get cut when things go south, and you will sometimes be forced to make crippling compromises in the quality of your applications to meet short-term business needs. That being said, you will often get the opportunity to directly impact the work of people who you see regularly and share in the success of the businesses your software supports, so there are tangible rewards to this avenue.

    8 ) If you decide to program software for a company that sells their technology, they tend to treat their engineers better than corporate IT shops, and cut their engineering staff last when things get bad. On the flip side, in tech companies there is a lot more pressure to produce and meet deadlines; if the software doesn’t get produced, there is nothing to sell, and the company goes under. You will also be less connected to the people who use your software since they often don’t work for the same company.

    9) The languages you can program in do not define your capabilities as an engineer, but they do determine how easy it is to achieve the goals you are tasked with. A language like C++ produces the highest-performance software, but becomes riddled with complexity when you want to use it to produce user interfaces or deal with cross-platform applications. Languages like Java and C# are great for producing applications, but can’t match the raw speed of C++. Almost all the GUI toolkits are a pain in the ass, but are a necessary evil to produce end-user applications (if you can’t stand pushing pixels around all day, don’t become an application developer). Dynamic languages are more flexible and easier to make mistakes with; compiled languages tend to be faster and more precise, but can sometimes make you feel like you are wearing handcuffs. My recommendation would be to learn C, plus either Java/C#, at least one web-development UI language (Flex, XHTML + JavaScript, etc.), and at least one dynamic language; you will learn things from each that make your mastery of the others more complete. They will also help you learn what your preferences are, and help you decide what you want to specialize in.

    These thoughts are obviously just my own experiences, but hopefully you will find them useful if you are considering getting in to the field. Whatever you decide, if you love programming in school or as a hobby I can assure you that you will also love it as a job. I wake up every morning and can’t wait to get to work to fire up my IDE and knock out some more code.

    2009.06.06 / 15 responses / Category: Uncategorized

  • More “Flex” to “Flash” Worries

    Pursuant to the renaming of Flex Builder to Flash Builder, I just posted the following comment to this article on The Flash Blog.

    I don’t really care what Adobe calls the tools, but it goes without saying that there is a clean separation of skill set between Flex and Flash developers. In fact, Adobe and Macromedia both did an admirable job of pointing this separation out at length when promoting Flex to the enterprise development community. I can only imagine that the companies chose to do this because of the Flash IDE’s image in the developer community as a tool for making animations and non-enterprise apps – a perception which frankly still holds true for Flash developers not using the Flex toolset.

    For everybody who already uses Flash and Flex, renaming Flex Builder to Flash Builder is not going to cause any serious issues; we understand the roles of both tools and can differentiate. Where the name change will be confusing is with future students and professionals evaluating Flash and Flex for the first time, and trying to decide which tool set they need to master and for what purpose.

    What I am most concerned about as a Flex developer is Adobe’s recent moves to blur the previously-clear definition between Flash media and Flash enterprise development skill sets. If Adobe continues this trend and decides to abolish the Flex name altogether and call it “Flash Enterprise” or something like that, people like me who develop purely with the Flex framework are going to have a much harder time targeting relevant employment opportunities. This will be just as difficult for Flash developers targeting rich media/non-Flex opportunities. The two specializations are individually necessary and distinct for different kinds of work, regardless of the platform’s capabilities.

    You stated the following in your post: “We as a community need to spread the word about what Flash really is now.” So, what is Flash now? As far as I can tell, it’s the same as it has always been: the most pervasive platform for running rich, interactive applications. There are two common ways to do that: using the Flash IDE and working in a media-centric fashion on the timeline, or writing script-and-tag-based applications using the Flex framework. There are other less-common ways, such as generating Flash content programmatically using any of the many commercial and open-source authoring libraries. Renaming Flex Builder to Flash Builder doesn’t change any of these facts, doesn’t change what the Flash platform can do, and doesn’t spread the word any further about what the Flash platform is capable of.

    I must ask: is this apparent need to change perception about the capabilities of the Flash Player really the purpose for renaming Flex Builder to Flash Builder? Is this the same reason behind renaming Flex Camps to Flash Camps? If so, then I’ll ask Adobe to please stop now. Adobe and Macromedia poured tons of marketing dollars in to promoting Flex development as a different activity from Flash development, and with good reason: they are different activities targeting different skill sets. Clearly Adobe agrees that this is the case, or they wouldn’t have two separate tools targeting each activity.

    Call the tools whatever you like, but unless the goal is to merge all the Flash-related tools and skill sets altogether (a horrible idea for reasons already outlined), please keep the differentiation between Flash and Flex development apparent.

    2009.05.18 / 2 responses / Category: Uncategorized

  • Apparently I’m Becoming a Flash Developer

    I just found out that Flex Builder 4 is being named Flash Builder 4, and the micro-conference that I’m speaking at this month that would usually be referred to as a Flex Camp is instead a Flash Camp.

    WTF? Unless they are integrating the Flash tools from the Creative Suite in to Flex Builder, I have no idea why they are calling it Flash Builder. Once again, marketing defies logic.

    Perhaps Adobe will explain the situation at some point.

    UPDATE: The Flash Blog attempts to clear up the matter here. I still don’t get it. This statement in particular by the author (in the comments) puzzles me:

    “@Everyone I can guarantee that the Flash IDE is not going away. I don’t know what else to say to convince you. I’m not one to BS my readers so I hope you will trust me on this.”

    So, now we have two products, the Flash IDE and Flash Builder… great. That’s not confusing at all.

    2009.05.16 / 2 responses / Category: Uncategorized

  • Flash Camp Orlando

    After a great event in Miami, the Flex community is doing it again with Flash Camp Orlando. Don’t be put off by the name – this is a Flex conference through and through, with the name being driven by some arcane motivations from deep within Adobe’s marketing department. However, since Adobe is sponsoring the event, they could call it Giant Lollypop Tomfoolery and I’d still be happy to support it.

    The event is taking place on May 29th, 2009 with an early bird special available until 5/15. There are going to be some great speakers there (with the exception of me, since I am a total ass hat). You’ll get to see brand new content plus a few popular topics being repeated from the Miami event.

    So what’s the vig? We’re talking $35 with the early bird for an all-day event including parking and lunch. That’s a steal – even more so if you get lucky and you end up with a prize worth more than the entry price, and Adobe always comes through with loads of great prizes so the chances are high that you will walk away with a little something-something (or even a big one – some lucky fellow got a full Adobe Creative Suite package at the Miami event!).

    If you are even remotely interested in or involved with Flex development I highly recommend you register right away. I’ll see you there!

    2009.05.12 / no responses / Category: Uncategorized

  • Client-Side Data Synchronization with Flex and BlazeDS

    As a Flex developer, unless you have been living under a rock for the last four years you know that LiveCycle Data Services offers Data Synchronization. This is implemented as a server-side product, and allows you to quite easily manage concurrent data access for many clients connected to the same server.

    But what if you need more than a single server? Cluster, you might say. Unfortunately, that doesn’t really work at any serious scale.

    At Highwinds, we build everything to scale to ridiculous levels because we’re a CDN and that’s how we roll. As a result, we use a lot of eventually consistent systems and design every component to scale horizontally. So, when we took to designing the next generation of the StrikeTracker platform, we wanted data synchronization and conflict resolution but we (a) didn’t want to manage it statefully at the server tier and (b) didn’t want to pay Adobe a bunch of money for LCDS just yet.

    So, we decided to implement client-side data sync. In essence, it boils down to the following elements.

    1) Whenever a client wants to change data (i.e. add something new, change something, delete something), it calls the server tier using RPC via RemoteObject.

    2) The server completes the call in a transaction against a replicated MySQL instance set up in master-slave configuration with hot failover. When the server call completes, the modification to the object has been persisted and a version number on the object has been incremented.

    3) The calling client receives a response saying “yep, the server processed your request – hold for confirmation from the message bus.” The object that was just processed by the server is placed in to a “limbo” state by the client.

    4) Using AOP, “after” advice is applied to the server-side component to dispatch a message to our message bus indicating what just happened.

    5) All clients are connected to one of many BlazeDS servers, which are in turn listening to command-and-control channels on our message bus for messages from all BlazeDS servers. All the BlazeDS servers eventually get the messages dispatched by their peers indicating which changes happened on other clients in the system via the message bus’s flood-fill algorithm.

    6) As the BlazeDS servers receive the messages from the bus, they push them to their clients. The clients then compare the type of message (new, change, or delete) with a collection of objects of the same type in their local memory, looking for matches based upon unique object IDs.

    7) If a match is found, the clients do some comparisons between version numbers to figure out if they have the latest version of the data or not. If they don’t have the latest data, they can react to conflicts much like LCDS does today. If the client which caused the original request to be processed receives confirmation from the bus that its message was broadcast to everybody, it takes its local copy out of limbo state indicating to the user that the process has finished executing.

    The system works on the principle of every object being uniquely identifiable by ID and class type, and being versioned in an ever-increasing fashion. By using a client-side controller mechanism for requesting data changes and putting the controller in charge of all RPC communication, message bus listening, and data management, we’ve come up with a very robust model for dealing with data synchronization on the client side.

    We can also give the client immediate feedback regarding their pending requests, and know that all clients will see the same data appear near-simultaneously. In the case where we have network latency or issues for clients in different parts of the world, the clients are built smart enough to deal with the latencies. Finally, we can use the approach without having to use JMS, which means one less server component – and if you already have a message bus (like we do) then you’ll know how nice it feels not to have to light up yet another one.

    We’re currently coding the implementation and expect to have it working this week, and after we get it going I expect to discuss it further on my blog. There’s certainly a fair bit of code to handle corner cases and concurrency issues, so I’m not sure how proprietary this approach is going to be, but I’m hoping that if we get it working I will be able to get permission to open source it to the community. In light of the fact that LCDS’s approach does not make sense for all use cases, this seems like something that a lot of people could put to use.

    I’ll keep you all posted as we go.

    2009.04.19 / 6 responses / Category: Uncategorized

  • A Peek Under The Tamarin Hood

    I love little details about the inner workings of platforms, like this snippet from Mason Chang about Tamarin and native methods.

    Even though all I wanted was a little AOP love, I’ve ended up learning a ton about virtual machines and ActionScript itself from Loom. Which is two utilities away from being finished, I might add – I started on ProxyFactory this weekend and SwfEnhancer is the last piece of the puzzle… :)

    2009.04.05 / no responses / Category: Uncategorized