0

If two people start at the same time in a company and one is lets say, hypothetically a hacker (not in an illegal sense but in a sense that he likes to dive in, explore and learn things by himself) and the other is someone who is constantly bombarding others for information (essentially getting others to do her work and tying up their time in the process).

Both are producing roughly the same amount of work.

Which is a better look? Someone who looks like they are fitting in, always asking and can often be seen with someone else sitting next to her or the guy who is quietly working away? Do employers have a preference? Does the "hacker" guy look like he's not fitting in?

The setting is a large software development company. Both workers are contractors with similar levels of experience.

I realize this can be a bit opinion based but there is a goal such that the "hacker guy" does want to increase his value in this company and hopefully get offered a permanent position. What is a more desirable approach?

Improve this question
6
  • 1
    I think there is a nice balance between the two. Diving in and figuring it out yourself, but asking just enough questions to get you where you need to go in a timely manner. – さりげない告白 Jul 3 '18 at 6:10
  • Are these people software developers? – Ben Mz Jul 3 '18 at 10:12
  • 1
    It depends on the workplace. Some places like collaboration and team effort while other places like independent people who can work by themselves. – Dan Jul 3 '18 at 16:05
  • 1
    Hacker vs Asker is a false dichotomy. Moreover, the question is slanted and prejudged towards the hacker-- of course no one wants a "help vampire'. But neither do they want a cowboy that transgresses rules and walks over people because he's "smart and can figure things out by himself". – teego1967 Jul 3 '18 at 16:38
  • 1
    @BenMz LOL! but no, it was a legitimate concern. By the way, I'm the "hacker" in this question. – solarflare Jul 5 '18 at 0:36
12

Which is a better look? Someone who looks like they are fitting in, always asking and can often be seen with someone else sitting next to her or the guy who is quietly working away? Do employers have a preference? Does the "hacker" guy look like he's not fitting in?

The real answer is going to be "it depends". And it depends on mostly what is at stake. If I have no idea how to configure an industrial firewall, and I'm being asked to fix production bugs on it because a setting went haywire, trying to do so with no idea what you're doing could be considered reckless and negligience.

If you're being asked to familiarize yourself with a code base or come up with a small module yourself to start, it's probably a lot better to do some self research on it before asking.

In the end, the best employee (that is also going to be percieved the best in most circumstances) is good at weighing the pros and cons of each approach and knows when asking is prudent vs when it is unnecessary. So in summary, exploring yourself is welcome and fine, but knowing when it's not a good idea is also tremendously important.

Improve this answer
5
  • 1
    i would imagine if you're being asked to familiarise yourself with a codebase you'd want to start by asking questions, rather than just reading it? – bharal Jul 3 '18 at 12:14
  • 1
    @bharal I'd expect you to ask questions only after you've done some legwork of your own and understood some of it. Unless your codebase is a complete and utter mess, code is really self explanatory most of the time. – mag Jul 3 '18 at 12:16
  • 1
    for a large codebase this is a fairly futile task though. For a smaller code base it would be possible, but I'd be very worried about the effectiveness of a team-member if they just went off and didn't talk to anyone all day and read hitherto unknown code. – bharal Jul 3 '18 at 12:20
  • 1
    @bharal As I mentioned in my answer, judgement is key there. One of the things that makes a good employee is to know when to ask questions. The codebase thing was merely an example and is not valid for all possible codebases, as much as the other example isn't valid for all possible configuration issues. – mag Jul 3 '18 at 12:22
  • Also you should be concerned about the long-term trend, not just the current sample. Judicious "asking" is necessary for a new team member, but the balance should shift toward more independent work as they become more familiar with the current status, priorities, and culture. – Peter Jan 29 '19 at 14:33
7

Yes, this is going to be opinion based.

There's wildly different levels of "hacking" and "asking".

A Hacker could be someone who knows a lot and can work confidently and constistently well, or it could be an uncontrollable nightmare of a renegade coder.

An Asker could consider questions and then ask the right questions of the right people at the right time, or they could be a nightmarish help-vampire.

Your question here is clearly weighted toward the hacker.

At the end of the day, it's based on the actual behaviour of the people involved - obviously, there's an idea level for both approaches, or a blend of the two.

Improve this answer
4

It all depends to what extent the 'asker' is going around, while he may look competent at first asking all these questions, he also may start to look incompetent and the see-saw of these two workers may start to lean towards the 'hacker'.

Another topic to consider is what type of project are you working on? From my experience there are some projects that you must rely on your colleagues for information or clarification which is viewed like a positive thing. Otherwise if you are given a lets say solo task to develop, asking around may start to influence the view of an incompetent person as I described before.

One more thing to take in consideration is your companies values and work environment. Is it agile and team-oriented? In that case getting an update by asking around can be viewed as a positive thing. If not, being a 'hacker' and being able to do your job on your own would without wasting other employees time and companies resources could be a plus.

To summarize I think it is best to be adaptive to the environment you are instead of magnifying one characteristic

Improve this answer
1

Almost universally, the answer is "asker".

For non-core engineering/science roles, the "hacker" simply isn't an option. You cannot "hack" business development - there isn't documentation about clients, for example, that would allow someone to work out anything meaningful without asking. You cannot "hack" management, because that's a relationship role, and if you're not forming relationships by asking questions and interacting with people then you're on course to fail.

Basically, you won't be able to "hack" non-engineering roles, because there isn't the documentation to "hack" it.

So the only role where the "hacker" is viable is a core engineering/science role. Note the "core" - the same restrictions above apply to sales engineering, for example.

Within this narrow band of roles, the only time the "hacker" is potentially better is where it is a sole-worker role. ie you've been hired to work on a problem and you're the only person working on it - eg the only engineer for a small company. Even then, if you're not asking about the business purpose...

For other roles, while there might be code that can be hacked, the business reasons behind the code won't be "hackable". Code only has a purpose when it solves a business problem. The business problem is rarely evident from the code, so the hacker will not be able to contribute meaningfully to solving business problems. Also, by the question, the hacker isn't talking to the business department to find out what they need solved, or if the solution presented really addresses the problem. The mythical "super-genius" who can solve problems perfectly and understand the business perfectly is exactly that - mythical.

Also, asking how to solve problems isn't "essentially getting others to do the work and tying up other's time in the process". It's forming relationships with your peers, it can involve pair-programming, and it is a much much faster way of learning than just sitting looking at code on your own. Nobody learns faster in isolation.

Asking stops wasted time and effort solving the wrong problem, or solving a problem that has already been solved elsewhere. Please be the asker, not the hacker. Companies like askers, not hackers.

The only time a hacker is potentially better is for a solo-development role.

Improve this answer
4
  • A business development person can hack by ignoring how the company performs sales, marketing, financial analysts, M&As, etc and doing things it her own way, perhaps even hiring her own people. – Ben Mz Jul 3 '18 at 14:59
  • @BenMz you're redefining "hacking" as per the OP's question however. – bharal Jul 3 '18 at 15:05
  • "he likes to dive in, explore and learn things by himself" - there is nothing that makes this specific to software development, a maverick business developement person could do this. – Ben Mz Jul 3 '18 at 15:10
  • @BenMz as i note, such a "maverick business person" is unlikely to find any sufficient documentation to cover the requirements so fully as they can get by without asking questions. also a business person who doesn't interact with their peer is... unlikely to be a business person for very long. – bharal Jul 3 '18 at 15:12
1

It depends, but the hacker is probably favoured by employers.

Few people are all hacker or all asker and a balance of the two is desirable. However I will compare two people, one who is much closer to pure hacker and one who is closer to a pure asker.

You say they both producing about the same amount of work. The asker is costing the company more money to do this because she is using all her time plus part of other people’s time. The hacker is only using his time.

The cost of delivering the output not the only consideration however. The quality of the output should also be considered. You could suspect that the hacker will product poorer quality work than the asker because he has less information. This is often not the case. Hackers often are interested in having a holistic understanding of the systems they work in where as askers know many discrete facts about the system. The understanding the hacker has can lead to better quality. Hackers also often learn by doing rather than by asking and have a more practical set of skills which often results in better quality work.

Hackers may do there work in a way this is different from the rest of the organization. Depending on the type of the work this may be considered a bad thing. If this is a customer facing position such as sales or support then people may be concerned that the hacker is inconsistent with the companies standards for messaging. If these people are software developers then people would say the hacker contributes more technical debt to the code base. In my experience, such concerns are rarely more important than delivering work in a quick and cheep way for the company.

The hacker and asker both run the risk of upsetting co-workers in different ways. The hacker will appear disrespectful to the way things are done. He may not be seen as a team player. The asker can be seen as annoying and a distraction. Because of the frequency the both interact with there co-workers the hacker will be disapproved of from time to time where as the asker will be annoying all the time. From an employer’s point of view the way the hacker causes interpersonal problems is more desirable because the hacker is actually exhibiting behaviour you want to see more of across the team, e.g. ownership in the task and independent thinking. The asker is less interdependent and less able to make decisions herself.

There are organizations and kinds of work where being the further on the asker end of the continuum is better, or at least more appreciated. These are however more than cases where being the more of a hacker is better.

Improve this answer

Not the answer you're looking for? Browse other questions tagged .