Blog Post

Homage to Basic

April 30, 2014 Freddy Guime Blog Post

It’s been a while…it has a sense of the old. You see it, but when you see the Beginner’s All Purpose Symbolic Instruction Code, it transforms everything around it. The letters become big and blocky, the monitor becomes concave, and all computers are grey. The keyboard feels heavy and has a personality, oh how I yearn for the times that Basic brings.

Like your first fling, you can’t never forget it. I would say it hasn’t aged as well as I would’ve liked it to, but it will forever a memory on most developers. Ah these younglings who have never experience such an era. It’s not even the language but what it meant to program back in the 80 and 90s.

…You could really understand a computer…

There was so little code between you and the metal. A single-task OS (sometimes not even that), a bunch of interrupts, a CPU that could only process an instruction at a time, back when 640k was too much. You could actually directly interface with the serial port and send bits (I still remember being ecstatic when I managed to turn on a single LED using one of the bits for the Parallel port by “printing” from basic to LPT1. It was a time of discovery, of wonderment and amazement. Of course that’s still happening, but let me indulge in the old-curmudgeon “Back-in-my-day…”

… You really really understood a computer…

Fat32, bootloaders, sectors, all of it. Today is very very hard to know what happens on the CPU. I work on an area where understanding the complexities and intricancies of the hardware pays large dividends. I’m talking about CPU L2 cache lining, evictions, branch predictions, concurrency, Main memory access semantics vs GPUs. And I claim that I don’t know today’s architecture like I knew the 8086 (or the Apple II c) for that matter. And don’t even let me get started with USB vs Serials and all the billions lines of code between me and those pesky transistors.

…You really really manipulated a computer with BASIC…

And it was great! You didn’t have to learn assembly to make a computer sing. I remember installing the Speech Synthesis card for the Apple 2 and making it read aloud what I typed. What a thrill that was. There was no software for it. You had to program it yourself, the manual came with instructions on what were the commands to send to what memory addresses.

I was untrained and unrefined and plain when I started programming BASIC. If anyone would looked at that code today, they would scream. It would have been the perfect example of many things that shouldn’t be done.

I was 9. and I was a Deity

In the christening that all developers go to, I still remember writing

10 print “hello world”

and then I added my first hack

20 goto 10

I was hooked

My flavor was the apple II c basic, and how I was so excited. Only 5 1/4 floppies, no hard drive. Terminal green screen, and not a care in the world. I would create silly things, a birthday card maker that printed text in those never-ending paper reams. The tick-tack of the dot matrix printer head still lodged in my memory. I remember creating my first bootable program…it was a matter of renaming a .bas a certain way, Android still does the same thing today 😉 and making it list the content of the current floppy drive at boot up.

I remember discovering how to center things on the screen…there was no internet back then, and books about programming in my neck of the woods were hard to get. How excited I was when I discover you needed to take the length of what you wanted to print, divide it by two, and then subtract it from the (halved) number of characters that you could fit in a line. Then you printed that # of spaces, and tagged what text you wanted. It was my first empirical algorithm.

I remember how I tried in that tight REPL until I got it.

Ah, those days.

When I moved to the x86, what a change. It had color, it had a better basic, it had peek and poke, and bload and bsave, and a hard drive. It has a shell, and TSR programs. Oh the days. I remember how I started creating more and more unrefined, crufty, yet cool as hell programs. The first one was simply just changing the Video Mode, oh lusty CGA, and then putting pixels on the screen. I finally learned about GOSUB.

My biggest memories were from when I decided to take my first consulting gig. I created a BASIC program that would show the different maps of my native country (Ecuador). I remember mapping every single line on the screen with line commands and point commands. I didn’t looked far ahead as to use files or image formats. It was all raw hand-coded BASIC.

I was 14

I remember how I panicked because the original basic could only hold so much memory, and my subroutine to draw one last map put it over the top. I couldn’t save nor load it. There was no github, no svn, nothing. I freaked out for twenty minutes until I realized that I had made a copy for a demo the day before in a 3 1/2 inch floppy. I lost a day’s worth of work, but I was so relieved it didn’t matter.

I remember learning empirically how to create sprites. I have so much flicker since I didn’t know nor understood about double buffering, yet it was my first video game. A sprite moved, and you have to shoot it down. Spacebar fired the missile, and the pattern of the enemy was so predictable. Yet I showed to anyone who would peek in my room. Those days I would eat lunch next to my computer while I tinkered in basic. It took a very persistent mom to drag me to the outside world and get sunlight.

I also remember creating what could be the predecessor of music-typing. I remember learning the piano and sometimes not feeling the pattern the music sheet was telling me to play. So I created an actual graphic music sheet composer that would play on that single-tone speaker, it even have legattos, and “:” and tempo. It was the most complex piece of code I created… Once I typed the last command I didn’t save, went for lunch, and then got distracted. When I came back my sister has rebooted the computer (ok it wasn’t mine, it was a shared computer for the whole family), and I lost it all…

Those are the experiences that shape you…

I was so angry, for the whole of two hours. Fuming, thinking this is impossible, I can’t do it again. But then remembering the end-result that I achieved once. It was still there, hinting at the greatness that I enjoyed for 20 minutes. it was possible to do it again.

And I did.

It took almost 6 hours of continuous programming (my first hack-a-thon I guess). But it was greater than my original one…how couldn’t it be, I discovered what I was doing wrong in the first one, how to make things simpler. And I immediately saved three copies, and learned the one shortcut that I will always from then on take the time to learn. F5, Alt-F-S, and today Ctrl-S. I typed the longest song that I needed to play for my piano class. I showed to anyone with a pair of ears that would listen. How proud I was. It was me, it was the computer playing for me, what I told it to. I made it do that.

Is so different than today. I stayed next to my computer to create video games, while today most kids stay next to their computer to play them (I know, I’m about to say ‘getoffmylawn’).

Basic was my first love. The reason that I became a Computer Scientist, there was just no other way. Before that day I remember saying “I want to be an Architect”, or a “Mechanical Engineer”, a Business Owner, I played with Legos, played with the Atari, played the piano…but that Apple II C and Basic sealed my fate. I felt like a deity. A Puppet Master that could do anything I wanted. I can change things, and I learned how to change things. It was so intoxicating, so simple back then. There was no object orientation, no dependency inversion, no unit tests, no databases and ODBC drivers, no IDE, no shell, no design patterns, no mouse, no Path (or classpaths) no installers or configuration settings, nor registries, there was nothing but you and the pureness of the machine in front of you…

It’s been 26 years since my first line of code was written, and when I close my eyes I do miss Basic. A clueless girlfriend, always meaning well, but get tangled so quickly in those goto statements, and really didn’t have too much to work with. I remember when I dumped her for C++. Such a sleazy, sexy and screwed-up language. I guess a guy is always interested in bad (language) girls…

I find it funny how I settled for the down-to-earth Java spouse, C++ was really wrecking my life. Still my first love will always be there and be special to me.

Happy 50th Birthday BASIC.

Freddy

JUG Post: Ok, I have a meeting, and am worried about no-show, what to do?

June 28, 2013 Freddy Guime Blog Post

So you are a Java User Group leader, and as you look forward to the schedule presentation a sinking feeling creeps up. “How many people are really going to show up?”, “Am I going to have pizza for everyone?”, “Will my sponsors be glad or mad?”

While not an exact science I went out and asked the Java Leader Community how did they deal with the problem. Here are some suggestions compiled from the list.

Why is it important?

Because I say so! Kidding!

The biggest issues are that there is food costs (that might need to be fronted by the group leadership), room costs and capacity (A meeting of 20 people might only need a whiteboard and some chairs, that will not work with a meeting of 100 people), and sponsorship agreements (‘Yes, every meeting we have 100 people coming! of course of course, um… these 20… are just the beginning, I’m sure they are just stuck in traffic or something…really….’)

Expect no-shows

The first part of planning your meeting is to expect people just to not show up. If the event is free, and is easy to register, one can conservatively prepare for a 70% attendance. If, for example only 60% shows up, then it really becomes only a 10% no-show instead of the original 40%.

Remind, remind, remind

A week before the meeting, send a reminder to your group about the event. Sometimes people seem to register and ‘forget’ about the event. As you get closer, send another reminder a day before the event. (Meetup allows this fairly easily).

If the Event is full, then ask for “help”

Another way to help control no-shows for completely full events is to send an email telling people to un-register if not attending. A special tip is to make the Subject message grab your attention, like  “We are full, please unregister if you aren’t coming”. That way the message doesn’t get lost in the member’s mailbox.
 

Overbook your event

Just like Airlines overbook their flights, you can overbook your meeting :). Plan for that 70% attendance, and allow registration for those extra seats.

Don’t announce the event too early

Today, the human race doesn’t plan further ahead than two weeks. If you announce the event too early, you’ll get people signing up when they really don’t know what their plans are. They tend to forget they signed-up for the event and will cross-schedule with something else. If you keep it within two weeks people will usually remember the meeting (and make newer plans accordingly)

Bargain on your Pizza

You have 100 people registered, and you want to control your no-show cost. Well, once you start placing order (like 10 pizzas), negotiate a good price. As an example Gray Herter can get Papa Johns to cough up specialty pizzas for 10$ each (they usually order 20). So if there is pizza wasted, at least is not as bad as paying full retail price.
You can try also calling ahead and giving a rough estimate of pizza you need, and as the event starts, call and confirm an actual number. It seems that some pizza places are flexible enough that this is not an issue.

Or don’t have Pizza but Books!

A trick from CEJUG is that they ask sponsors to give them books for their attendees. The promise of a book is much alluring than pizza and they love it (since all our members love anything Java), plus they get it to take something home.

Watch that weather channel, and topic

Bruno Souza shares that weather plays a role in the number of now-shows. He plans for a 50% attendance,
 – If it rains, he expects less people
 – If it’s an intro topic, he expects more people (seems like people dropout less often if the topic is introductory)
 – If it’s in a remote area (out in the woods), he expects more people (since Java presentations are not as frequent in remote areas, people tend to show up for the opportunity)

Charge!

The best way to really reduce no-show numbers reported is to charge for the event. Put the money where the registration is! Bruno reports that once you start paying your no-show percentage drops from 50% to 20%. For paid events he will still hand out free passes for speaker guests and/or sponsors (and for those free tickets he still expects 50% no shows)

It’s always about the community 🙂

Live happens, and while sometimes we wish things are always the way it seems to be, when it’s not we just have to juggle it. With these tips at least you avoid some of the (sometimes costly) mistakes we all went through and prepare better for your group and/or organization. Hope this helps! (it did for me!).
Special thanks to the Jug Leaders in no particular order (Hildeberto, Frank N, Csaba Toth, Linda van der Pal, Gray Herter, Carl Trusiak, Alexis Lopez, Bruno Souza) for the tips!
Freddy Guime
Chicago JUG Community Leader

For those of you going to JavaOne San Francisco 2012

September 14, 2012 Freddy Guime Blog Post

See if you can spot me! I’ll be tweeting my location @fguime and be wearing the above t-shirt

Hope to see you there!

Ah, and if you like the t-shirt, drop me a line, if there is enough interest we can create a store!

Freddy Guime

An experiment with resumes

April 17, 2012 Freddy Guime Blog Post



tl;dr
I usually review developer resumes when we want to hire, so I went into a thought experiment and decided to create what would be my  “ideal”” candidate resume using my own experience.

Sifting for that golden candidate
We do our share of hiring every 4 to 6 months, as our team grows, and it always starts the same way. We cast the widest net (and publish on the high profile sites like Monster, CareerBuilder) and then get a pile of chaff with some wheat (sometimes!). So I was thinking, what is it that I look at a resume, and if I were to look, how would I present it better?

Bear in mind that the techniques described here are used when we  have to go out and cast our nets into the resume-world. Our first choice (a la Joel Polsky) would have been to get a referral, or indoctrinate someone, but if that doesn’t work, then we do go out and try to find a good candidate out there. Because of the volume of resumes, we have to forego the individual as an individual and apply sifting techniques (we know we are all special and unique, and getting referrals or resumes from people we know is our real first choice, on which is more about the interview than the resume). Alas, take my technique with a grain of salt 🙂

So after some thinking, there are two people that need to evaluate your resume (at least where I am coming from). The first is the high-end noise filter. In our case is our super cool HR person has to at least select those that applied with the right skills! She is the one that looks that the super star applicant have at least a minimum of x years of Java experience, understands multi-threading and hopefully works in the Financial industry (the third one is a maybe).

If you made it past that HR/Headhunter filter, then you need to be evaluated by the real “Developers”, and those are harder to impress (as we can usually smell if someone is fibbing, mind you, we can get false-positives and true-negatives, but in general if you really don’t have experience on a particular area, another developer  could catch it on your resume; there are some telltale signs).

So what am I looking for in a resume? In order of importance

  • Verify that Language and Experience looks OK (this is agreeing with what H.R. saw)
  • Continuity of employment (while not necessarily a bad thing, large discontinuity of work shows at least some exploratory questions if the candidate comes in)
  • Understand what you did within those three/four jobs that you took
  • Figuring out where in the organization you were positioned
  • Trying to understand your skill level
Verify that Language and Experience looks OK
The first step is easy enough, it is just looking that effectively you have xx years of Java experience, that you are willing to work in Chicago, that your experience is relevant (For example, we are not too interested in J2EE, mostly J2SE as that is what we work on) and that you meet our bare minimum requirement (human, possibly with BS).
Continuity of employment
We have found that sometimes there are significant gaps in employment in certain resumes that we get. Again, while in itself that is not “bad”, it does raise questions;  at least it is an opportunity to make conversation. Sometimes we found that candidates don’t put experience in because they wouldn’t be able to get referrals, or their job turned very ugly (or at least uglier than usual). For us, even that is a good talking point, as we could explore why that job was so horrible, (and we can then make sure how would we fit in that picture). Most people we have found (especially once they hit a certain work-years) become  predictable in their continuity of employment. Again, not a deal-killer, just another question mark.
Understand what you did within those three/four jobs that you took
This is probably the hardest thing to figure out on resumes, and the reason is that job experience is usually not side-by-side. Plus it is the area that most people try to showcase how much they know about the subject-matter, and fit what tools they used, and try to describe what team they were working on. In all this is where the meat of the resume is at, and as such is hard to digest in one gulp.
I first start by trying to discern what you really did (This is where the fibbing shows its ugly head). Words like “Part of a team that developed a highly concurrent one million line of code system” are a big warning sign, ditto for “Lead a team in the ….”.
The reason is that for once, the achievement that is listed is for the “whole team”, rather than your individual contribution (The ‘leaders’ might be OK, even though we ran into leaders that haven’t typed a single line of code, and were just managing the project. That was a no-no for the position we were looking at the time). We did have interviewees that essentially created the html page for the large multi-threaded million lines of code and as such his experience as we were interested in were for naught. It is much much better just to list your part specifically first, like “Created the exchange component for the Options Trading Software, as part of a ten person team.” That way we know what you did, and that you were working with a team. That is much better!
The next part that gets gummed up in the work section, is understanding what technology did you use to create such a beautiful piece of code :). Java Beans, ThreadPools? MySQL, Sql Server. You see, some people list everything they ever touched in the first part of the resume (I have seen resumes with Windows 95, and MS-DOS 5.2 as part of Skills), but most of it is irrelevant, and really, the only thing useful is what you did in your past job (maybe two). The rest can, and will be, outdated (Try using Turbo Basic now…).
In that sense we want to understand what were the tools and technology that you used in your last job. That is what you have fresh in your mind and what you can probably start using tomorrow. This is the hardest part to get out of the work section of the resume as sometimes is not explicitly set, and/or is gummed up within the description. “Used Profiling and Analysis tools to diagnose and fix Memory crashes”. Hm, does that mean that you use JHat? VisualVM? good old-fasioned System.free()? Memory crashes? Out of Memory errors, or JVM Crashes?
Figuring out where in the organization you were positioned
This is extremely hard. Some of it is the “Being part of a Team” syndrome (almost only in name). Other is huge lines like “Supervised the Task force for Continuous Improvement.” If the task-force is made of only one person, then that means that you were supervising yourself (which doesn’t sound to super-visory anymore). We have run into many Vice-Presidents of something-or-other just to find out they would have translated to “Senior programmer” in any sensible work-place. This is part of a Dilbertism (is that even a real word, if it isn’t i’m christening it! :)) on which companies promote in title but not in pay. And while this practice is only good for that company (we don’t do that), is bad and confusing for everyone else. Some people do try to mislead (or genuinely believe they are  Software Development’s Senior VP of Bank of America) with the title. For us it just makes sifting that much more difficult. We understand that is part of the “Getting hired” game, but in all seriousness, would you like a company that hires you because you have  Senior VP in your title, or because you achieve a lot?
Knowing where you were within the org chart tell us immensely what you were doing (a Senior VP who is way down in the org chart, would not be creating  vision statements, but actually making sure something got programmed and delivered) and what expectations to exert on you. The more people that were directly reporting to you, the more of a leadership role you (and we) would be expecting for your new job.
Trying to understand your skill level 
The last part is understanding the real accomplishment. Did you use JMS? how? do you know Design Patterns? Have you really troubleshooted a JVM hprof? These are highly technical questions, and sometimes are very hard to discern from the resume. This is the part that “wows” developers.
Let’s say that you made some performance improvements. If you put it on the resume as “Made performance improvements in responding to data events”, I would be mildly interested, just because that could really mean anything. I can turn-off logging today and made performance improvements on almost any application. If you tell me instead “Reduced latency within our application from 200ms  to 10 ms by implementing live-spinning locks and reducing hand-over queues” then there is something that makes our imagination go wild. You make me start thinking on the lines of “Hm, maybe he could do something about our market data latency”. And that’s a win. If you manage to get another developer wondering where you could use that particular skill, it’s very likely that you will come to a face-to-face interview and continue talking like humans (and you can really show off your expertise).
So in that sense, once you’re past the H.R. required keywords, write for the developer, he is the one that will ultimately say yes-or-no to bringing you in.
Ok, so what would my resume look like?
Like this!
In all, a resume would have two pages (I don’t mind if it’s clearer). The first page is for H.R. and the second is mostly for Developers. So let’s take a look at the new Resume Revolution

 

The first page contains at the top the “Best Feature” section. This is just a paragraph of why I’m worth considering (pretty standard fare). Your elevator pitch essentially.
The next part “Work Overview” lists all the relevant experience in a tabular format. At most the past 3 jobs would do (or pick the relevant ones). Notice that the first row is “Year”, and immediately addresses my first concern/flag of employment continuity. The last job is highlighted, indicating that’s the most important one for me.
Notice how things are broken down so that it’s not all in one paragraph format. In the “Duties Performed”
I write a line or two of mostly what I did, mentioning just a little of the technology I used. The Position before Leaving shows the highest job title I had before leaving (this avoids creating entries for when I was just a Junior Programmer). This just highlights the best things I did when I was employed by company X.
In the next rows I mention what languages, database, version control, IDE, Tools, Secondary tools I used on each of those jobs. This makes it clear what did I use for each job I held. I also highlight the “Years of Experience” using each main programming language by adding (6 Years) next to the language name. The “Skills” section contains a very toned-down version of what I consider helped me the most when doing my job (Concurrency, Swing -> Speed).
In all, the first page of the resume is done for the purpose of snaring that H.R. person to first think that the resume has enough experience, and to gently introduce a developer to what I have done across my last three jobs.
The second part, is mostly geek-speak. Let’s take a look

 

I have a section called Developer’s skills (Java), on which I list what I know within Java, an example to clarify that knowledge, and a situation where I used that knowledge. You see, the issue is that saying “I know multi-threading” can mean either “I know that deadlocks are bad”, or it could mean “Why live-spinning is best for Intel’s multi-core cpus instead of AMDs”, and everything in between. That’s why there are two more columns that help “hone-in” the level of skill that you have. Honesty is still the best policy. If you really inflate your knowledge too much on paper, it will show immediately in an interview. If you inflate it somewhat only it will show in your performance (when you’re asked to troubleshoot a deadlock, and don’t know where to start…). So I help the interviewer to know exactly where I land on my expertise with concrete examples of what I have done. If you really showing off more than one language, you could have more Developer’s Skills (Grails) etc in your resume. Just include them if it’s necessary for the job that you’re applying for.
The last two sections are to help answer the questions on “Where did you study” and “Where are you in the Org Chart.” The Company Organizational Chart tells how many employees were on the particular unit I was working on (UIC has 100k employees, or something like that, but in the particular unit I was part of, we were only 50), and where did I fit in that (including how many people I supervised). It becomes clear who is reporting to me, and who do I report to.
In Conclusion
I would love to see resumes like this (I’m being selfish 🙂 ), because that just help my work of understanding what everyone did in their career path. But hey, I’ll share mine, and hopefully, the idea of restructuring the resume so that is easy to read will catch on fire (or not, but hey, I’m hopeful). We have been stuck with a resume structure that is old, and I think a little re-thinking is not a bad idea! As a work in progress I definitively see more value than traditional resumes, and there is probably even more room for improvement! What’s your take?BTW
if you read this far and like this post recommend it to your friends (upvote it in HN as well!) Also, check out my podcast!, and subscribe!

Lastly if you want to listen to my geek rock band, check out my videos here!

Thanks for reading!
Freddy

 

Episode 11. New Year’s Resolution: Object Thread Safety! + Listener feedback, and the birth of a Google Group!

December 16, 2011 Freddy Guime Blog Post, Multithreading 0:37:58

In this podcast we air our first question/feedback from our listener and dive a little into it (related to Dependency Injection). We also talk about how to create Thread Safe objects (There is the easy way, and the hard way). And at last! we have a Google group where you can add/post comments and open discussions.

Our new Google Groups
http://groups.google.com/group/javapubhouse/

Questions, feedback or comments!comments@javapubhouse.com

Subscribe to our podcast! (http://javapubhouse.libsyn.com/rss)
ITunes link (http://itunes.apple.com/us/podcast/java-pub-house/id467641329)

“HELLO WORLD”

September 23, 2011 Freddy Guime Blog Post

Welcome to Java Public House, the podcast (and blog) dedicated to the hard working Java professional! 

This blog was created to help those of us who have to work with Java day in and day out, and its mission is simple, is a podcast created by a developer for developers. You can think of it as “free” training seminars in downloadable form. We will cover Java related topics (such as multithreading, Swing, JavaFx) and gear it towards understanding these topics a little bit better, and while there are a tons of sites out there that describe good things about Java, we tried to be a little different.

This podcast talks about how to program in Java; not your tipical system.out.println(“Hello world”), but more like real issues, such as O/R setups, threading, getting certain components on the screen or troubleshooting tips and tricks in general. The format is as a podcast so that you can subscribe to it, and then take it with you and listen to it on your way to work (or on your way home), and learn a little bit more (or reinforce what you knew) from it.

Within this podcast we are open to get questions from everyone, and the most popular then gets slotted for next week’s topic (as easy as that!). So, let’s learn together, and have fun (and become better professionals!), a win win!

Why should I listen to this guy? (A little bio)

Ok, so my name is Freddy Guime, I have three kids, two cats and one wife
I Presented at JavaOne twice (and scheduled to present in 2011) on topics related to multithreading and Swing.

I work for Optionscity Software Inc, as their Director of Client Technology (don’t worry, it stills involves programming 90% of the time), and wear many hats (usability expert, performance Guru, and coffee-to-code processor. Within Optionscity I’m proud of what we create (it’s very innovate, and cutting edge), and always love the challenge of pushing Java to its limit.

Happy Programming!

Freddy