Browsing articles in "Blog"

Trolls, Burdens, and Happiness.. Oh My!

Jul 20, 2010   //   by Karen Lopez   //   Blog, Professional Development, Social Networking  //  No Comments

Many of you have been members of our communities since we started them more than a decade ago.  So you’ve seen over the years how great things can be when we collaborate and you’ve seen how bad it can be when things go down the tubes.

Fortunately, we have a great set of moderators to ensure that the worst of the worst postings don’t make it anywhere near your inbox.  But from time to time we’d get posts that were more about attacking the other person that offering up constructive criticism about the content of a post.

There are different approaches to managing teams and communities when it comes to negative feedback versus personal attacks.  Some of our members think that we should all have thick skins and learn to deal with personal attacks, while others support our position that posts that are not constructive should not be approved.

We need to realize that there are all types of people out there and we all get our self-actualization in many ways. Trolls (people who spend their day making insulting posts in blog comments, board posts, and mailing lists) try to lift themselves up by smashing others down. Others take a different approach – by taking risks, learning, and continuing to improve themselves.

I want to encourage everyone to stay in the latter group. And have compassion for those who haven’t yet figured out how to improve themselves. You don’t have to put up with insults to be compassionate, but you also shouldn’t carry those insults around.  Whether they come from an online community or a team meeting, the best way to deal with them is to reject the thought, verbally or internally, and move on.

I think it must be a painful life having to find and point out mistakes or weaknesses in others in order to feel good. It’s such a burden, when we all have enough burdens to carry already.

As a community manager I know that for every person who posts, there are probably hundreds or thousands of others who learned something from your post.

Carry that with you, not the posts or comments of the people trying to push you down to prop themselves up.

Andy Leonard, a SQL Server Blogger, has a great series of blog posts on a similar topic. In his post, A Turning Point, he mentions some of his strategies of dealing with positive/negatives. 

Andy’s Secrets to Happiness

If you look around at work and life in general, there’s plenty of things to discourage you. The above quote says to me "You have a choice about how you react." Personally, I’ve made a conscious decision:

     Don’t do misery.

I did some misery in the past and I think that’s enough for one lifetime. From here on out, no more. When life hands me lemons I give them to my lovely bride Christy (Blog@ChristyLeonard) and she makes a tasty lemony dessert out of them. Also:

     Do not let people live rent-free in your head.

Sorry, them’s the rules. If you’re in there you either need to pay up or move out.

Check out his excellent series.

And don’t carry the burden that someone else has tried to put on your shoulders.  You have enough to do already.

Looking for a Job? Some Free Advice That’s Paid For #1

Jul 16, 2010   //   by Karen Lopez   //   Blog, Careers, Professional Development, Reviews  //  4 Comments

Lately I’ve been helping clients find employees/contractors and helping friends find jobs.  I’m not in the job helping business, but I do have many years of experience screening resumes for clients and pointing people to opportunities  I thought I’d share with some some of my most valuable job finding tips.

Before I get to the details, I’d like to point out that I’m not really going to make a distinction between employment and contracting in this post. The tips here, for the most part, can apply to either type of job.  In addition, the market itself treats both contractors and employees the same.  Contract versus Permanent really involves legal, tax, and accounting issues more than anything.  There are significant financial differences between the two, but that’s another post.

 

1. The best jobs often never get posted or sent to an agency for placement

In 25 years I’ve never gotten a job or a contract via responding to an ad. I know people who have done that successfully.  It just hasn’t been something that I’ve needed to do. I’ve just rely on word of mouth to find out about opportunities. The reason why the best jobs aren’t posted is that it costs companies time, money, and risk when they hire via ads.  Why? Because they get unfiltered resumes that need to be screened and candidates need to be put through a series of screening interviews just to get to a manageable list of candidates. It’s truly a fire hose of resumes that show up.  And they really don’t want to drink that water.

When I screened resumes from posted ads, I’d guess that 95-99% of the resumes we received were non-starters: the applicants had little or none of the skills we were looking for. This is especially true for more advanced positions.  We also saw a lot of resume claims that turned out to be less than truthful. I even once received my own resume with someone else’s name pasted on the top.  That’s how difficult hiring from ads is.

So most of the best jobs aren’t ever posted anywhere.  Instead, a manager or team is asked "do you know anyone looking for a job?  We need a widget administrator who can start tomorrow."  So the teams start asking their network "who’s looking for work" and more often than not someone knows someone who fits the bill, or close enough.

Some organizations do work within regulatory environments that require all jobs to be posted, but in my experience, those jobs are often already filled before the posting goes up.

Does that mean you need to start diving through corporate dumpsters to find out where these non-posted jobs are?  Nope. If you want to find the best jobs, don’t start with the ads (websites, newspapers, craigslist).  Start with your network for friends. 

You don’t need to know about the jobs; you just need to know the people who know about those jobs.


2. Jobs posted via agencies are stuffed with Yes/No Tests…and almost no one has all the answers right.

You’ve seen these postings: full of acronyms, 10 versions of RDBMSs, coding tools, degree requirements, language requirements, etc.  Even if the technologies listed have almost nothing to do with the job.  Why do agencies do this?  The first reason is that if the overload the requirements, they can better manage that fire hose in point 1.  The second is that Yes/No technical skills ("Do you have 10 years experience with RDF?", "Do you have 10 years experience with SQL Server 2012?")  are much easier to screen on than more subjective skills ("Can you explain the tradeoffs of Kimball versus Inmon?", "Can you properly normalize an OLTP data model for a retail store that might someday get into the ecommerce business?").  The people screening these really need clear and unambiguous tests for screening resumes.  Their clients are often clueless that this sort of gate-keeping is happening.

The job posting overload is also used later for negotiations. "We won’t pay as much for someone who has only 9.42 years of RDF".  They know that it isn’t necessary for the candidate to have all the answers, but when they don’t, they want to keep more of the referral fees.

So don’t let a job posting slip by just because you don’t meet all the criteria in the posting.  You should be able to meet most of it and you should be able to do the job before submitting, but cross those gates when you are negotiating, not when you are trying to figure out if you are allowed to apply.  And don’t be an idiot by pointing out to an interviewer where your skills don’t fit. Be honest in your assessment, but don’t draw attention to weaknesses.  I had a great candidate who sailed through the interview with the tech team, only to blow it with the hiring manger and HR rep by mentioning more than 5 times that he didn’t have the most recent skills in one of the requirements.

Don’t let a list of True / False tests work against you.

 

3. Don’t tell anyone except your spouse/partner and your pets that you are interviewing for a specific job.

I worked with a bright woman who was relocating to a great city for her spouse’s job.  So she had given notice at the client site and started looking for a new job in the new city.  She had many exciting opportunities there and shared those stories with lots of details of where she was interviewing and how much it paid. 

One of our co-workers told a friend in that city about the job.  He interviewed and got it.  A week later another co-worker interviewed with her next great opportunity and got that job.

If she had just been vague about the opportunity or, ideally, just kept it all quiet, she may have landed one of those jobs.  She thought she was safe because the city was so far away.  It’s a small world.  All this happened before the Internet, too.  With the speed that information travels these days, posting that you are interviewing with a company on your Facebook or other social network might just mean you are giving that job away to someone else.  By all means, tell people you are interviewing; just don’t give away the details.  Be overly vague.

Think of job hunting like treasure hunting: the fewer people who know about the treasure, the less likely you will have to share it.

 

4. Don’t be afraid or embarrassed to tell people you are looking for work

There was a time when looking for a job meant that you had some character flaw, that you were unemployable or that you were a bad employee.  Of course, unemployment was really low, you could keep a job for 25 years, and you got a nifty gold watch before you retired.

With unemployment hovering around 10% or more in some locations, many people are looking for jobs.  If you keep quiet about or worse, lie about your job hunting quest, you are shutting out the very people who can help you find that best job I mentioned in point one.  We are fortunate that in the IT world, there are still plenty of open jobs that pay well and offer great opportunities.  If you are having trouble finding out about opportunities it means you need to work on meeting more people, not searching more job boards.

I never think poorly of someone who tells me they are job-hunting.  In fact, my first thought is usually "Cool! How exciting to be looking for new projects".  Which brings me to my next point…

 

5. Don’t just look for a job; look for a project.

Most hiring in IT happens for these reasons: 1) A new project is starting and the company can’t find enough people internally to staff it.  2) A new project is starting and the company doesn’t have the skills it needs to staff it. 3) Someone has left the company and the organization needs to hire someone to fill their role.

Almost all the job opportunities that come across my desk are due to the first two points.  Rarely the third reason. That could be because my work is overly focused on the project work, but I also think it is due to the project-orientation of most IT positions.

So don’t tell people you are just looking for a job; tell them you are also looking for a project.  Ask people about their projects. 

Get them thinking about their projects…and you…and their projects…See? You’re doing that right now, aren’t you?

 

6. Stop calling yourself Unemployed.

I cringe every time I see one of my social network buddies update their profile with UNEMPLOYED at UNEMPLOYED.  When a hiring manager sees an update pop up on their Facebook, Twitter, or LinkedIn pages, do you think they say "Ooh — an Unemployed.  Daym, I need to get me one of those!"

BTW, I absolutely cherish the "time off" I have between engagements. This is when I do all my research, training, public speaking and building my network.  How can I afford to do that?  It’s all in my business model….but that’s another post. I don’t tell people I’m unemployed.  I know that some people think of it that way, but that’s their problem, not mine.  I run a business.  I don’t make money just via billable hours. Again, another post.

Tell people who you are: "Sr. Project Manager" or "Data Architect".  Then tell them you are looking for a new project…or job.

And while we are on this subject, don’t call yourself "Part Time Data Architect", "Job Hunter", "On the Dole" or "Given Up Looking for a Job".  I’ve seen those in profiles and it just doesn’t make me want to pick up the phone and talk to them.

You might have a slightly different take on some of these recommendations and I’d like to hear about that.  The more we share our tips, the more we help each other. 

There’s more coming: Part Two of this FATPF on job hunting and leveraging Social Networks coming soon.

Required Reading: TOP 25 Most Dangerous Programming Errors

Feb 1, 2009   //   by Karen Lopez   //   Blog, Compliance and Regulation, Data, Data Breach  //  No Comments

Error ISS Trainin Module SCAM-CE GHF-CE

The SANS Institute and the Common Weakness Enumeration (CWE) project released last week a list of the top 25 programming errors.  This resource, which lists the error and the project phases/tools/processes to which they apply, should be required reading, on a regular basis, by all team members on a development project. While this page refers to programming errors, I believe this is a great checklist of development errors, as some of them apply to architectural and methodological issues.

SANS Institute – CWE/SANS TOP 25 Most Dangerous Programming Errors

Experts Announce Agreement on the 25 Most Dangerous Programming Errors – And How to Fix Them
Agreement Will Change How Organizations Buy Software.

Project Manager: Bob Martin, MITRE
Questions: top25@sans.org

(January 12, 2009) Today in Washington, DC, experts from more than 30 US and international cyber security organizations jointly released the consensus list of the 25 most dangerous programming errors that lead to security bugs and that enable cyber espionage and cyber crime. Shockingly, most of these errors are not well understood by programmers; their avoidance is not widely taught by computer science programs; and their presence is frequently not tested by organizations developing software for sale.

The impact of these errors is far reaching. Just two of them led to more than 1.5 million web site security breaches during 2008 – and those breaches cascaded onto the computers of people who visited those web sites, turning their computers into zombies.

Even in 2009 I am constantly struggling with getting vendors and my own developers to acknowledge the importance of dealing with these issues.  As a project manager, I’m the one ultimately responsible for ensuring that delivered systems will do no harm, but that’s one of the hardest parts of my jobs.  Why?

  • Most of my newer developers have never received any formal education, training, or testing on many of these issues.
  • Many vendors rely on customer requests or customer production testing to identify these errors. 
  • Most packages, with anti-reverse engineering clauses in their terms of use, forbid inspecting code for these vulnerabilities.
  • Business users often don’t understand the short and longer term implications of neglecting these professional issues…nor should they have to.  But since we don’t have a "building code" or standards of practice in IT, we architects and project managers have no external authority to fall back on when users want to cut the security and protection steps of a project.
  • Many people still naively cling to the belief that the tools they use automatically protect them from these weaknesses.

Of particular interest to those of us working in the data and information responsibilities of a project are these development errors:

CWE-20: Improper Input Validation

It’s the number one killer of healthy software, so you’re just asking for trouble if you don’t ensure that your input conforms to expectations…MORE >>

I am constantly asked to allow the programmers to research and implement the validation rules for input data, since this cuts down on the amount of analysis needed and allows coders to get coding faster….and it always leads to less than acceptable validation, as coders don’t have time to go research the data — they need to be coding.  It’s a vicious circle.

CWE-89: Failure to Preserve SQL Query Structure (aka ‘SQL Injection’)

If attackers can influence the SQL that you use to communicate with your database, then they can…MORE >>

This involves using the lowest level of authority required to get the job done, among other things.  Yet developers usually want to develop, test, and deploy while using administrator-level authority.  Code should not be tested while running under administrative authority since it should not be deployed that way, either.  It is amazing to me how many people tell me they *must* have the SA password in order to code.  They may need some administrative-like rights, but no-one needs the SA account to develop code.  Not even DBAs.

I work with a few vendors who tell me that their packaged application must run under the SA account and the Windows Administrator, in production.  No amount of discussion with their "lead developer" will change their minds. It’s pure laziness and cluelessness to design a product that requires these rights. I have convinced many a client to replace software (and therefore vendors) that require this type of authorities.

I find this list to be of sufficient importance that I’m recommending that teams schedule a specific effort to review, discuss, and create an action plan for addressing these items.

So go pour yourself a coffee/tea/cola/water and start reading.  Your customers will thank you.

Blog Categories

Subscribe via E-mail

Use the link below to receive posts via e-mail. Unsubscribe at any time. Subscribe to www.datamodel.com by Email


Categories

Archive

UA-52726617-1